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Sammanfattning 


Denna uppsats inleds med en introducerande undersökning dar vi finner att mjukvaror för 
förvaltning av Business Rules inte är använt av många svenska organisationer. 
Förundersökningen drev oss att undersöka hur Business Rules förvaltas inom svenska 
organisationer. Först sammanställdes en översikt över de fakta som finns tillhands inom ämnet 
för Business Rules samt lämpliga sätt att hantera Business Rules. Genom de förberedande 
studierna identifierades några brister som kan finnas i svenska organisationer som inte använder 
Business Rules och dessa ledde till en första och övergripande forskningsfråga. Frågan 
formulerades som följer: Hur förvaltas BR i IS och IT i svenska organisationers dagliga 
verksamhet? Den har sedan delats upp i sju stycken delfrågor som framställts utifrån 
problemområdet. Dessa sju frågor försöker vi besvara genom intervjuer och e-postfrågor i fyra 
svenska organisationer. 


För att besvara forskningsfrågorna har vi tagit hjälp av de fakta och modeller som finns tillhands 
inom ämnet Business Rules. Exempel på fakta och modeller är Rule Maturity Model, Business 
Model, Zachmans framework och Business Rules Approach. De övergripande svar som vi kom 
fram till är att Business Rules inte är något känt eller vanligt förekommande begrepp i svenska 
organisationer. Vanligtvis används termer som affärsregler eller verksamhetsregler för att 
beskriva BR i svenska organisationer. Det verkar inte heller finnas något strukturerat sätt att 
behandla Business Rules på inom svenska organisationer, utan de finns företrädesvis gömda och 
implementerade i programkod eller databaser. Det finns dock mindre undantag till exempel vissa 
delar inom Boverkets organisation och det finns även en önskan att förvalta BR på ett bättre sätt 
inom andra svenska organisationer. 


Huvudbegrepp: Business Rules, Business Rules Approach, Business Rules Management System, 
Rule Maturity Model, Business Model, Enterprise Decision Management, Verksamhetsregler, 
Affärsregler. 
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1. Inledning 


Alla organisationer har regler som styr organisationen i den dagliga verksamheten. Utan regler 
skulle en anställd behöva värdera och välja mellan olika alternativ varje gång ett beslut behöver 
tas (Ross, 2003). I en organisations dagliga verksamhet finns det löpande processer som påverkas 
av dessa regler (Morgan, 2002; von Halle, 2002). Organisationens medlemmar behöver varje dag 
ta ställning till vem som får ha tillgång till företagets databas, vilka kunder som ska accepteras 
och så vidare. Skulle det inte då vara väldigt bra om dessa operativa beslut, som grundas på regler 
och tar både tid och resurser för organisationen, kunde automatiseras på något sätt? Informations- 
Teknologi (IT) och Informations-System (IS) har blivit en vanlig företeelse i dagens 
organisationer och regler finns automatiserade i organisationernas olika system och applikationer. 
Denna automatisering av organisationens processer kräver att regler förvaltas på ett strukturerat 
sätt (von Halle, 2002). 


Om en organisation inte hade några regler så skulle den ha svårt att existera. Det skulle inte 
finnas några planer på hur och av vem beslut och uppgifter skulle skötas. Det skulle krävas att 
man i varje situation var tvungen att fatta nya beslut. Regler är som Morgan (2002) beskriver det 
något som kan liknas vid organisationens skelett. Reglerna kontrollerar organisationens relationer 
med kunder, leverantörer och samhället i stort. Det finns egentligen regler som styr överallt i 
organisationen och den skulle falla ihop utan dessa. Regler finns till följd av den 
informationstekniska utvecklingen vanligen i organisationernas system som exempelvis i javakod 
eller i databaser. Ibland verkar de osynligt men reglerar så att exempelvis en kund inte får läggas 
in i systemet utan att få ett kundnummer. 


Morgan (2002) skiver att organisationens medlemmar inte är medvetna om den affärslogik som 
organisationens regler beskriver och står för. Därmed anser Morgan att essensen i en metod som 
kallas Business Rules Approach (BRA) är att skriva ner alla regler som styr verksamheten, 
eventuellt kalla dem Business Rules (BR), och separera reglerna från de övriga IS/IT-systemen. 
Med att separera dem från övriga system menar Morgan att Business Rules lagras för sig, men att 
de sedan är åtkomliga från de övriga applikationerna och systemen inom organisationen. I detta 
arbete ingår också att strukturera reglerna och göra dem identifierbara. Vidare behövs det även 
göras en selektion av vilka regler som är möjliga att koda och vilka som bara bör finnas i text 
eller i någon regelstruktur. En Business Rule skrivs enligt Morgan med ett speciellt språk och ska 
begränsa verksamheten i den mening att regeln beskriver vad som far eller inte får hända. Det är 
dessa kodade regler som styr den dagliga operativa verksamheten i en organisation och som 
denna undersökning behandlar. (Morgan, 2002) 


Krav på uppdatering eller konstruktion av nya Business Rules kan komma inifrån organisationen. 
Det kan gälla behörighetsregler om vem som har tillgång till vad, vem som får beställa varor från 
leverantörer eller vem som får uppdatera organisationens databas, men dessa krav kan också 
komma utifrån organisationen genom skatteregler eller andra lagar och förordningar. Det finns 
alltså två olika typer av Business Rules, antingen interna eller externa (Bajec & Krisper, 2005). 
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Interna Business Rules som beskrivits ovan är regler som finns inom organisationen och styr 
verksamheten. Exempel på interna regler är att bara en systemansvarig har tillgång till att 
uppdatera vissa databaser eller att kunder far 20 % rabatt endast om de beställer för minst ett 
tusen kronor. 


Externa Business Rules kommer från omgivningen utanför organisationen och kan exempelvis 
vara förordningar utfärdade av regering eller myndighet (Bajec & Krisper, 2005). De externa 
reglerna har organisationen ingen möjlighet att styra över men de kan fortfarande vara 
implementerade i organisationens system. Till exempel regleras den summa som dras i skatt från 
de anställdas lön av vilken skattesats den anställde har, denna skattesats är ju inget som 
organisationen kan påverka. De Business Rules som styr verksamheten kan vara implementerade 
i IS och IT eller finnas nedskrivna i olika procedurförteckningar, manualer med mera (Morgan, 
2002). I denna uppsats kommer vi att fokusera på de Business Rules som finns implementerade i 
organisationers IS och IT. Vi ämnar undersöka hur de Business Rules som är automatiserade och 
operativa förvaltas av några organisationer. 


Flera välrenommerade forskare och yrkesverksamma (von Halle, 2001; Morgan, 2002; Ross, 
2003) som beskriver Business Rules anger en mängd potentiella fördelar med Business Rules 
Approach. Därför borde svenska organisationer också kunna dra nytta av Business Rules 
Approach i sin dagliga verksamhet. Enligt Business Rules Approach så finns inte Business Rules 
till för att stödja IT utan IT ska finnas till för att stödja Business Rules i verksamheten (von Halle, 
2002). En viktig uppgift för en modern organisation idag är att synliggöra och använda den 
kunskap som finns inom organisationen. Inom denna förvaltning av kunskap används Business 
Rules av en organisation för att hantera och strukturera sin kunskap. Organisationens medlemmar 
har kunskap om principer, procedurer och begränsningar, dessa kan omvandlas till Business 
Rules som stöd för det dagliga operativa beslutsfattandet. Forskare och yrkesverksamma anser att 
organisationer behöver nya IT-system för att separera sina regler från andra komponenter inom 
organisationen. Detta för att de vet att reglerna existerar, vad reglerna är, var reglerna finns och 
hur reglerna kan förbättras. Business Rules Approach används för att göra dessa regler synliga för 
organisationen och hjälper den att förvalta sina regler. Organisationen kan med separerade 
Business Rules, verksamhetsregler, fininställa sin verksamhet och snabbt gör ändringar i sina 
regler som svar på en föränderlig omvärld. Därmed kan organisationen också snabbt hantera 
förändringar och bli mer flexibel. Morgan (2002) skriver att Business Rules är kodad kunskap om 
företagets eller organisationens verksamhet. 


1.1 Bakgrund 


Mycket av den litteratur vi kom i kontakt med när vi läste kursen ”Konstruktion av Business 
Rules system” vid Lunds Universitet påvisar användbarheten av Business Rules (BR). Under ett 
projektarbete, som ingick i kursen, implementerades Business Rules i ett case som behandlade 
delar av en organisation som levererade fruktkorgar till olika företag och organisationer. En av 
våra uppgifter var att konstruera ett UML-diagram (beskrivs i kapitel 3.10.1) för att sedan med 
stöd av detta konstruera BR enligt Morgans principer (Morgan, 2002). Det avslutande steget i 
projektet var att programmera en applikation som använder dessa regler. Arbetet med detta gick 
ganska bra även om det inte är helt okomplicerat att konstruera regler enligt Morgan (2002) 
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koncept och det krävs mycket träning innan det blir flyt i konstruktionen. De egentliga 
svårigheterna uppstod när dessa regler skulle implementeras. Vi upptäckte snart att det var 
mycket enklare att implementera reglerna direkt som javakod än att tydligt ange reglerna och 
sedan anropa dem från olika applikationer. Implementering av regler direkt i javakoden var både 
enklare och snabbare. Men när vi sedan ville ändra en regel var vi tvungna att leta upp regeln i 
javakoden. Detta tog mycket mer tid i anspråk än om vi noga hade strukturerat reglerna och noga 
angett vilka regler som användes och var. Många gånger tvingades vi även skriva om en hel 
metod i javakoden för att uppdatera en regel. Vi insåg att det även borde förhålla sig på samma 
sätt hos företag och organisationer och att det därför antagligen är mycket vanligt att Business 
Rules begravs i kod någonstans i systemen. Detta ger problem längre fram när regler behöver 
uppdateras eller tas bort då de är svåra att hitta (Morgan, 2002). 


Kursen vi läste vid Lunds Universitet väckte stort intresse för området Business Rules, men även 
en hel del frågor. Våra inledande frågor drev oss att undersöka svenska organisationer och deras 
användning av Business Rules och Business Rules Approach. Använder organisationer i Sverige 
Business Rules i någon större utsträckning och finns det mjukvara tillgänglig för att förvalta 
dem? För att undersöka detta närmare sökte vi via Internet efter mjukvarutillverkare som 
tillverkar mjukvara för Business Rules. Vi fann åtta stycken (se listan nedan) och bestämde oss 
för att söka information genom dessa. Vi formulerade ett brev (Bilaga 3) som vi via e-post sände 
till dem där vi frågade huruvida de hade några svenska kunder och om de i så fall kunde hjälpa 
oss att få kontakt med några företag som använde deras system. Vi blev ganska förvånade över 
svaren. Vi fick svar från fyra och de svarade att de gärna lämnade referenslista över kunder men 
angav samtidigt att de inte hade några svenska kunder. Det verkar som om svenska organisationer 
är ointresserade av området Business Rules eller av hur de förvaltar sina Business Rules. 


Vi bestämde oss för att försöka finna Business Rules hos några svenska organisationer för att se 
hur de fungerar i en verklig miljö och hur de används. Kanske används det en annan terminologi 
så att vi finner Business Rules under begrepp som verksamhetsregler och affärsregler. Vår första 
idé var att genom undersökningar finna Business Rules och beskriva hur de förvaltas i de 
organisationer vi undersöker. Vi vill även få en översiktlig bild av hur brett utbudet är av 
mjukvaror för att förvalta Business Rules. 


Lista över ett antal företag som tillverkar mjukvara för BR-förvaltning (BRMS). 
- Fair Isaac, http://www.fairisaac.com/fic/en, 
- Gensym, http://www.gensym.com 
- Idiom Software, http://www.idiomsoftware.com 
- flog, http://www.ilog.com 
- Oracle, http://www.oracle.com/technology/products/ias/business_rules 
-  Versata, http://www.versata.com 
- Visual-Rules, http://www.visual-rules.com 
- Xpertrule, http://www.xpertrule.com 


För dagens systemutvecklare är det också väldigt viktigt att skapa system som är anpassade för 
organisationen som ska använda dem. Forskare menar att Business Rules Approach är ett 
värdefullt redskap för systemutvecklare som vill utveckla system väl anpassade för och i fas med 
organisationens verksamhet (Morgan, 2002). Business Rules Approach innebär att 
systemutvecklare kan skapa ordentliga kravlistor. Kravlistorna anger behoven och kraven en 
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organisation har på ett nytt eller uppdaterat IT-system. Skrivna regler kan återanvändas och 
programkod kan genereras utifrån Business Rules vilket underlättar utveckling av system eller 
mjukvara (von Halle, 2002). Detta gör ämnet ytterligare intressant för oss och de som arbetare 
eller studerar inom det systemvetenskapliga området. 


1.2 Problem 


Att alla organisationer har en mängd regler, Business Rules, som begränsar och styr 
verksamheten råder det ingen tvekan om. Men då vi inte finner några svenska företag som ingår i 
undersökningar eller finns som kunder hos de tillverkare vi varit i kontakt med undrar vi hur de 
förvaltar sina Business Rules, för i princip alla organisationer har Business Rules i någon form. 
Det verkar som svenska organisationer har hamnat på efterkälken i den Business Rules revolution 
som enligt von Halle (2001) sker på området. Det är de Business Rules som inte syns eller är 
omedvetet implementerade som kommer att ställa till problem för organisationer. Dessa gömda 
Business Rules ligger och lurar i systemen och det är bara en tidsfråga innan de börjar ställa till 
problem. (von Halle, 2001) Sverige är ett IT-tätt land (The Global Information Technology 
Report, 2008) och svenska organisationer har till hög grad tagit till sig IT och IS i sin dagliga 
verksamhet som till exempel olika Enterprise Resource Planning- (ERP) system. 


Enligt von Halle (2001) kan Business Rules underlätta hur organisationen hanterar sin 
verksamhet. Följande fyra punkter beskriver de brister som kan finnas i dagens svenska 
organisationer. 


e Organisationer har Business Rules implementerade i systemen men utan struktur. 

e Vetskapen om vilka Business Rules som är implementerade i systemen saknas. 

e Ansvarig för verksamhetsregler, Business Rules, och dess implementering, uppdatering 
med mera saknas. 

e Det är svårt för användarna att spåra eller tyda de regler som används i IS- och IT- 
systemen. 


Om de svenska organisationerna står utanför Business Rules-utvecklingen kan det stå dem dyrt 
då omvärlden utnyttjar Business Rules för att utveckla flexibla och konkurrenskraftiga 
organisationer. Just denna flexibilitet framhåller många förespråkare som främsta argument för 
att använda Business Rules (von Halle, 2001; Morgan, 2002; Ross, 2003). Det kan innebära att 
svenska organisationer förlorar i konkurrenskraft när de inte kan förändra sin organisation och 
anpassa sina regler till omvärlden i en lika snabb takt som konkurrenter i andra länder. De 
organisationer som är mest framträdande i Business Rules-sammanhang just nu kommer främst 
från USA, England, Frankrike och Oceanien (BR-Community, 2008). BR är ett bra 
konkurrensmedel och ett bra stöd för att snabba upp de dagliga beslutsprocesserna men verkar 
förbisett i svenska organisationer. Dålig struktur för att behandla Business Rules på ett effektivt 
sätt och att mycket arbete går åt för att hitta Business Rules, är typiska problem som von Halle 
(2001), Ross (2003) med flera beskriver i den litteratur och i de undersökningar vi funnit. 


Von Halle beskriver att ett problem är att många organisationer är omedvetna om det speciella 
med BR. Von Halle påpekar att Business Rules finns gömda som delar av processer, 
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beskrivningar, policys, manualer eller i systemdesign. Detta gör att Business Rules utsätts för 
risker som att förloras, glömmas eller att de görs omöjliga att ändra och uppdatera. Andra 
nackdelar med att inte ha någon struktur över Business Rules är att medarbetare i organisationen 
inte vet vilka regler de egentligen skall använda. Detta gäller kanske speciellt när Business Rules 
används i systemen för att ta operativa beslut. Om organisationen inte har någon insikt eller 
kontroll över de Business Rules som används uppkommer känslan av att ”datorn” tar besluten 
och bara ger svaret ja eller nej. Eftersom det i våra inledande studier inte verkar som om svenska 
organisationer separerar Business Rules på detta sätt vet förvaltarna kanske inte vilka Business 
Rules som används i systemen. 


För en modern organisation är det ytterst viktigt att kunna förändra sig som svar på en föränderlig 
omvärld (Jacobsen & Thorsvik, 2002). Om det tillkommer nya affärsmöjligheter eller 
organisationens konkurrenssituation förändras behöver organisationen snabbt förändra sin egen 
verksamhet för att kunna fortsätta vara konkurrenskraftig. Om då reglerna för verksamheten finns 
begravda i programkod kan processen med att förnya verksamheten bli alltför långsam (Morgan, 
2002). Skatteregler eller andra lagar och förordningar, andra affärsavdelningar, kunder, 
konkurrenter och generella marknadsförändringar i organisationens omvärld bidrar alla till att 
organisationens Business Rules måste förändras. Business Rules påverkar och vägleder 
organisationens medarbetare i hur de ska agera och ta beslut. Förändringar i Business Rules 
påverkar också den informationen som finns lagrad i organisationens IS-stöd. Business Rules 
Approach används som ett sätt att förbättra förvaltningen av en organisations alla regler genom 
att öka organisationens kontroll av den kunskap som organisationen har om hur, varför, när, var, 
och av vem som reglerna genomdrivs. En organisation kan med Business Rules Approach få 
bättre kunskap, förståelse och kontroll över sina Business Rules (von Halle & Goldberg, 2006). 
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1.3 Begreppsbeskrivningar 


Nedanstående begrepp är tänkt att fungera som en inledande förklaring av de viktigaste 
koncepten som vi använder i denna uppsats. Varje begrepp kommer att förklaras djupare i olika 
kapitel längre fram i uppsatsen. Denna lista är också tänkt att användas för att lättare finna vad de 
olika förkortningarna vi använder betyder. Vi ber därför er läsare att lägga denna sida på minnet. 


Business Rules (BR): är regler som begränsar, styr och leder en verksamhet. BR kallas ofta för 
verksamhetsregler, affärsregler eller policys/bestämmelser. Men vi räknar inte in alla dessa olika 
regler i begreppet BR. BR för oss är de regler som styr den dagliga verksamheten. De BR som vi 
specifikt kommer att behandla är de automatiserade och operativa. 


Business Rules Approach (BRA): är ett ramverk med formaliserade metoder som används för att 
förvalta och automatisera BR. 


Business Rules Management (BRM): är förvaltning av BR. 


Business Rules Repository (BRR) & Rule Repository (RR): är en lagringsenhet för BR och regler i 
allmänhet. Regler kan sammanföras och nedtecknas, sparas på en gemensam plats. 


Business Rules Engine (BRE): BRE är mjukvaror som hjälper en organisation att förvalta och 
automatisera sina BR. BRE hanterar exekveringen av en organisations BR, vilka BR som ska 
exekveras och i vilken ordning. 


Business Rules Management System (BRMS): Ett BRMS är en heltäckande mjukvara för att 
förvalta och automatisera BR. Ett BRMS utvecklas för att organisationens affärsavdelning ska 


kunna hantera hela sin verksamhet med fokus på BR utan hjälp från IT specialister. 


BR-Stewards: ska kunna skapa nya BR, kunna se förändringar och utveckling i organisationen 
och dess omvärld och uppdatera eller ta bort BR som svar på detta. 


BR-Analyst eller -Analytikern: ska ha det övergripande ansvaret för att BR följer en standard, 
uppdateras, raderas om inaktuella, inte förekommer i dubbletter med mera. 


BRR-Administrator eller -Administratören: har ansvaret för BRR och att det används konsekvens 
i BR och mellan olika BRR. Denne har också ansvaret för att en BR-formatstandard följs och att 


en BR identifiering finns. 


Fallorganisationer: kallar vi de organisationer som vi har genomfört undersökningar hos. 
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1.4 Forskningsfrågor 


Följande fyra punkter, vilka vi kom fram till i problemområdet, beskriver de brister som kan 
finnas i dagens svenska organisationer. 
e Organisationer har BR implementerade i systemen men utan struktur. 
e Vetskapen om vilka BR som är implementerade i systemen saknas. 
e Ansvarig för verksamhetsregler, BR, och dess implementering, uppdatering med mera 
saknas. 
e Det är svårt för användarna att spåra eller tyda de regler som används i IS och IT- 
systemen. 
Dessa har lett oss fram till följande forskningsfrågor. Vi har formulerat dem så att en huvudfråga 
delas upp i ett antal underfrågor. Denna uppdelning görs eftersom huvudfrågan känns bred och 
utan fokus. Vi har brutit ner den till de delar vi med ledning av vår problemställning finner 
intressanta att undersöka. 


1. Hur förvaltas BR i IS och IT i svenska organisationers dagliga verksamhet? 
Hur är de automatiserade reglerna implementerade? 

Hur underhålls de automatiserade reglerna? 

Vem underhåller de automatiserade reglerna? 

Finns det någon form av Rule Repository? 

Är reglerna medvetet implementerade? 

Finns de inbäddade i programkod, exempelvis Java eller C++, eller är de 
separerade från systemet? 

g. Hur beskrivs BR i organisationernas terminologi? 


moan oD 


1.5 Syfte 


Syftet med denna uppsats är att visa hur BR förvaltas, fungerar och används i en verklig miljö i 
några svenska organisationer. Eftersom BR i svenska organisationer är ett outforskat område kan 
denna uppsats bidra med kunskap om BR. Genom att vi presenterar vara fakta kan de 
organisationer vi undersökt, studenter och amnesintresserade fa en inblick i vad BR är, hur det 
förvaltas och används av de organisationer vi har undersökt. 


1.6 Avgransningar 


Vi avgränsar denna uppsats till att bara undersöka regler som är implementerade, operativa och 
automatiserade i IS- och IT-systemen hos nagra svenska organisationer. Vi kommer inte att 
undersöka BR som finns pa andra platser inom organisationen i till exempel pärmar eller 
pappersarkiv. 
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Det finns flera olika sorters regler och reglerna finns överallt inom en organisation. De regler vi 
intresserar oss för är BR. Men även BR finns spridda i organisationer. Exempelvis kan vissa BR 
finnas i pärmar och mappar i något arkiv medan andra finns i manualer, databaser eller javakod. 
Detta är bara några av de ställen där BR kan hittas. Vi finner det inte intressant att undersöka eller 
beskriva de regler som styr exempelvis industrirobotar i en produktionslinje. Dessa regler är 
oftast i form av parametrar och matematiska beräkningar. I stället riktas vårt intresse mot den del 
av BR som finns automatiserad och som används för att samla in och tolka data i 
organisationernas IS- och IT-system. Dessa operativa BR kan finnas synliga för användaren men 
kan även vara dolda i systemen. 


Vi har i problemområdet beskrivit att det saknas litteratur eller beskrivningar av hur BR fungerar 


eller förvaltas av svenska organisationer. Vi kommer därför att rikta vårt intresse mot några 
svenska organisationer. 
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1.7 Disposition för uppsatsen 


1. Inledning — Inledningsvis presenteras en bakgrund till BR och 


f _ varför vi har valt att studera BR i svenska organisationer. Efter det 
följer en problembeskrivning, presentation av forskningsfrågor samt 
syftet med denna uppsats. Kapitlet innehåller även våra 
begreppsbeskrivningar, forskningsbeskrivning samt denna 


disposition. 
2. Förstudier 
3. Business Rules 


4. Tillvägagångssätt 


5. Kort om våra 
fallorganisationer 
6. Hur förvaltas BR i våra fallorganisationer — detta kapitel redovisar 


6. Hur förvaltas hur BR förvaltas av våra fallorganisationer. Detta redovisas utifrån 
BR av våra forskningsfrågorna, vilka är representerade som rubriker i kapitlet. 
fallorganisationer 


| 2. Förstudier — detta kapitel beskriver hur vi har genomfört våra 
förstudier. 


3. Business Rules - detta kaptitel presenterar hela undersökningens 
teoretiska ramverk för området Business Rules. Här ges en 
grundligare beskrivning av BR och BRA 


© 4.Tillvagagangssatt — detta kapitel beskriver hur undersökningen har 
- genomforts. Här beskrivs också materialinsamlingen och valda 
undersökningsmetoder. 


5. Kort om våra fallorganisationer — detta kapitel ger en 
övergripande presentation av de organisationer som vi har genomfört 
våra undersökningar i. 


7. Diskussion och svar på forskningsfrågor — detta kapitel diskuterar 
det som redovisats i föregående kapitel. Diskussionen genomförs 
genom att knyta an till den teori som har presenterats i kapitel 2 och 
har utgångspunkt i uppsatsens syfte och frågeställningar. Kapitlet 
avslutas med att vi ger svar på våra forskningsfrågor samt förslag på 
vidare forskning kring ämnet BR. 


7. Diskussion och 
svar på 
forskningsfrågor 


Figur 1.1: Disposition 
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2. Förstudier 


Vi inledde vårt arbete med att söka litteratur som behandlar BR och BRA. Eftersom intresset för 
BR har vuxit de senaste åren, både inom akademiska kretsar och i företagsvärlden, (Morgan, 
2002) fanns det en hel del litteratur tillhands, bland andra von Halle (2007) & (2001), Ross 
(2003) och Grayham (2007) och vi fann flera artiklar och böcker som var intressanta för vår 
uppsats. Genom vår inledande litteraturgranskning noterade vi att svenska organisationer inte 
förekom i den litteratur som behandlade BR och litteraturen var företrädesvis på engelska och 
behandlade organisationer i engelskspråkiga länder. Vi kunde i vår inledande litteraturgranskning 
inte finna någon undersökning som behandlade BR inom en svensk organisation. 


Efter vår inledande litteratursökning genomförde vi vår e-postundersökning med företag som 
tillverkar mjukvaror för BR, vilken är beskriven i kapitel 1.2 ”Bakgrund”. När vi tog kontakt med 
mjuvarutillverkare ville vi endast finna hur stort utbudet var och om de hade några svenska 
kunder. Vi gjorde ingen kvalitativ bedömning eller analys av de data vi fann. Det är en naturlig 
del inom forskning att använda både kvantitativa och kvalitativa metoder och vi såg inte heller 
någon konflikt i detta (Kvale, 1996). Syftet med undersökningen var att försöka hitta företag i 
Sverige som använde ett BRMS eller BRE för att förvalta sina BR. Vi blev ganska förvånade 
över svaren vi fick. Det var inte någon av dessa tillverkare som svarade att de hade några svenska 
kunder. Vi ställde oss frågan om svenska organisationer är ointresserade av området kring BR 
eller förvaltar de sina BR på annat sätt? Eftersom Morgan (2002) och von Halle (2001) skriver att 
de flesta verksamheter har en mängd regler som styr deras verksamhet undrade vi hur dessa 
förvaltas i svenska företag? Vi bestämde oss för att försöka finna BR ute hos några svenska 
organisationer för att se hur de fungerar i en verklig miljö och hur de förvaltas av några svenska 
organisationer. Vi kunde med hjälp av vår inledande e-postundersökning klarlägga ett syfte för 
vår uppsats, nämligen, att med vår uppsats visa hur BR förvaltas, fungerar och används i en 
verklig miljö i några svenska organisationer. 


Tidigt i forskningsprocessen gjorde vi upp en lista över områden och aspekter av BR som vi ville 
behandla i vår litteraturgranskning. 
1. Historiskt perspektiv. 
a. BR utveckling senaste 10 åren. 
2. Vad är BR? 
a. Hur kan BR se ut? Exempel. 
3. Hur bör BR implementeras? 
4. Var finns BR nu implementerade? 
5. Vem, vilka, har vanligtvis ansvaret for BR? 
6. Hur kan man forvalta BR, vilka olika verktyg finns idag tillhands? 
7. Rule Maturity Model. 
8. BRi Zachman framework. 
9. BRoch Business modells. 
10. Kritik mot BR. 
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I litteraturgenomgången ville vi ge våra läsare en tydlig bild av vad BR och BRA är. Vi inleder 
vår därför med en kort historisk översikt av BR. Detta gör vi för att läsaren skall få en djupare 
förståelse över vad BR är genom att få veta varifrån det kommer samt hur det har utvecklats 
genom tiden. För att läsaren ska kunna förstå våra slutsatser, analyser och problemdiskussioner 
tyckte vi det var viktigt att kunna presentera hur BR kan se ut och hur BR kan skrivas. Det är 
även viktigt att i litteraturgenomgången presentera vad tidigare forskning har kommit fram till 
vad gäller hur BR ska implementeras, var de kan implementeras, vilka som vanligtvis har 
ansvaret för BR samt hur en organisation kan förvalta BR. Vi ville även sätta BR i ett större 
sammanhang för att visa hur BR kan samspela med en organisations övriga delar och instrument. 
Därför tar vi även upp BR i Zachman framework och BR i Business Modells. Vi ansåg även att 
det var viktigt att finna kritik mot BR. Det var viktigt att inbegripa några undersökningar som har 
funnit negativa aspekter av BR för att denna undersökning inte bara skulle förespråka BR utan att 
också granska dess eventuella svaga sidor. För att kunna presentera det vi ansåg nödvändigt i vår 
litteraturgenomgång inleddes granskningen av böcker, artiklar, rapporter och information på 
webben. 


Under arbetet med uppsatsen upptäckte vi ytterligare några områden som vi ansåg vara viktiga att 
ta upp i litteraturgenomgången och några aspekter av BR som vi velat förtydliga mer. Rule 
Maturity Model (RMM) beskriver en organisations mognad med avseende på BR och visar BRs 
effekt i olika stadier. Anledningar till att vi har valt att ta upp RMM är att den kan underlätta för 
oss och våra läsare att förstå olika organisationers assimilering av BR i deras dagliga verksamhet. 


2.1 Litteraturgranskning 


Vi ville skapa oss en gedigen teoretisk kunskapsbas att stå på innan vi genomförde våra 
empiriska studier. Vi tog del av flertalet böcker och gick igenom och sammanställde ett antal 
artiklar som vi fann, företrädesvis genom sökning på ELIN, Electronic Library Information 
Navigator, (ELIN, 2008). Sökorden som vi främst använde för att finna material var i 
kombination med ”Business Rules”: Approach, Engine, Repository, Management och 
Knowledge. För att ytterligare fördjupa litteraturgranskningen analyserades också flera av 
böckernas och artiklarnas referenser. I vår sökning efter litteratur till stöd för metoder och teorier 
hade vi nytta av våra tidigare studier inom Informatik och speciellt av kursen i kvalitativa studier 
på Lunds Universitet. Artiklar vi sökte var sådana som gav oss nya insikter, beskrev ett avgränsat 
område av BR eller BRA eller kunde ge oss stöd i våra metodval. Vår inledande litteratursökning 
resulterade i en litteratursamling på sex böcker om BR och en mängd annan litteratur. Detta 
material har analyserats och vi har valt ut det material vi funnit mest relevant för vårt 
forskningsområde. Många artiklar har vi kunnat sålla bort genom översiktligt läsande av 
artiklarnas abstrakt eller inledning. När vi under arbetets gång har saknat information i 
litteraturen har vi genomfört en mängd litteratursökningar. Dessa sökningar har skett genom hela 
arbetets gång och har varit en iterativ process för att finna fakta. Detta för att kunna hitta litteratur 
eller information om ett avgränsat område av BR och BRA. Det vi fokuserade våra 
litteratursökningar på var gedigna beskrivningar av vad BR och BRA är, samt hur dessa kan 
användas i en verksamhet. Men vi sökte även information till stöd för våra forskningsmetoder. 
Syftet med litteraturgranskningen har varit att få en översikt över de kunskaper som redan finns. 
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Vi har sökt efter relevanta begrepp och teorier och letat efter motsättningar angående BR och 
BRA. För litteraturgranskningen har vi använt oss av riktlinjer som Bryman (2002) och Backman 
(1998) anger. 


2.1.1 Internetkällor 


Internet är en informationskälla där det inte finns någon enkel väg för att undersöka en viss källas 
autenticitet. Vi har därför varit mycket kritiska i valet av internetkällor. Vi har genomgående 
använt information som skrivits av för oss välkända källor eller finns på seriösa eller allmänt väl 
ansedda hemsidor. När vi har använt olika företags hemsidor för att hämta information om 
företagen har vi varit medvetna om att denna information inte är objektiv. Vi har ändå i 
undantagsfall hämtat information från dessa när det gällt till exempel fakta om någon produkt 
som ett företag tillhandahåller. Vi har även förhållit oss kritiska till den information som funnits i 
communities och bloggar angående BR och BRA. Sådan information är inte alltid opartisk. 


2.1.2 Tryckta källor 


I litteraturgranskningen har vi genomgående använt oss av källor som är välkända och väl 
ansedda eller sådant som är väl refererat. Detta inkluderar kursmaterial såsom artiklar och 
undervisningsmaterial men även artiklar och uppsatser publicerade med universitets och 
högskolors godkännande på exempelvis ELIN (ELIN, 2008). Vi har försökt hålla oss kritiska till 
det material som vi använt och mycket har sållats bort. Några personer som Ross, von Halle och 
Date är frekvent förekommande i litteraturen om BR, både vad gäller tryckta källor och 
internetkällor. Vi har därför aktivt sökt efter andra källor för att få ett vidare perspektiv och för att 
styrka dessa källors teorier. 
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3. Business Rules 


En av de viktigaste uppgifter en demokratisk och civiliserad stat av idag har är att skapa lagar 
och regler som medborgare och organisationer verksamma inom staten ska följa. Dessa lagar och 
regler är inte bara till för att styra utan även för att skydda de som lever och verkar i staten. 
Regler och lagar är också till för att skapa ordning inom staten men även i samverkan med andra 
stater och organisationer. Dessa lagar och regler talar alltså om hur myndigheter, medborgare, 
företag med flera ska bete sig och förhålla sig till varandra. (Egbert, 2005). På samma sätt har alla 
företag och organisationer regler som används för vägledning i den dagliga verksamheten. Utan 
regler skulle en anställd behöva värdera och välja mellan olika alternativ varje gång ett beslut 
behöver tas (Ross, 2003). Regler är alltså något som nationer och organisationer har handskats 
med under lång tid. Men det är inte förrän på senare år begreppet BR har vunnit mark inom 
området för organisation och verksamhet. 


3.1 Kort historisk översikt 


Intresset för BR har vuxit under de senaste åren, men konceptet är inte alltigenom nytt (Morgan 
2002). Ursprunget för BR kommer ifrån kretsar inom artificiell intelligens där olika typer av 
regler har använts för att kunna representera kunskap. I sådana kunskapsbaserade system kunde 
mänskliga kunskaper och resonemang kodas och lagras som regler i sofistikerade nätverk. 
Reglerna var skrivna enligt speciella förutbestämda mönster eller språk för att en dator skulle 
kunna tyda dem (Bajec & Krisper, 2005). Dagens BR utvecklades inte som ett svar på något nytt 
tekniskt verktyg utan kommer ifrån visioner och målsättningar satta av yresverksamma inom 
affärsområdet. Visioner och målsättningar är att kunna ge företag bättre metoder för att utveckla 
affärslösningar understödda av IS/IT. Den första publikationen som använde termen BR 
publicerades 1984 av Daniel S. Appleton. Daniel definierade termen BR till "... [A]n explicit 
statement of a constraint that exists within a business's ontology." (Daniel, 1984, s.146 refererad i 
Ross, 2003, s.183) I mitten av 90-talet specificerades BR när rapporten GUIDE Business rules 
project report skrevs av en grupp inom IBM. Rapporten skapades för att utveckla en standard för 
BR for att definiera termen och förklara vad BR verkligen ar. GUIDE definierade BR till ”a 
statement that defines or constrains some aspect of the business. It is intended to assert business 
structure or to control or influence the behavior of the business.” (Morgan, 2002, s.6) 1997 
formades officiellt den ickekommersiella forskningsgruppen Business Rules Group med malet att 
utveckla standarder av alla aspekter av BR. Ar 2003 publicerade Business Rules Group ett 
manifest for BR som kallades Business Rules Manifesto. BR Manifestet ar tankt att kort och 
koncist förklara de grundläggande principerna av BR. Manifestet finns tillgänglig pa svenska 
samt flera andra sprak (Business Rules Manifest, 2008). Ar 2007 publicerades den senaste 
versionen, release 1.3, av The business motivation model (BMM) av Business Rules Group med 
titeln "Business Motivation Model: Business Governance in a Volatile World." (Business 
motivation model, 2007). BMM är, enkelt beskrivet, en modell som företag kan använda for att 
planera sin affärsverksamhet med fokus pa vilka mal företaget har samt med vilka medel 
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företaget ska nå målen. BMM har en affärsmässig syn på BR istället för en teknisk och ger BR en 
framstående roll i modellen. De senaste åren har det skrivits några böcker samt flera artiklar som 
behandlar BR (Ross, 2003; Morgan, 2002; Halle, 2001; Valatkaite & Vasilecas, 2005). Det finns 
även sedan några år tillbaka en online Community där forskare och yrkesverksamma kan mötas 
och diskutera BR (BR-community, 2008). 


3.2 Vad är BR? 


BR är en term som många inom området för IT och ekonomi använder men få verkligen kan 
definiera (Morgan 2002). Morgan (2002) skriver “Basically, a business rule is a compact 
statement about an aspect of a business. The rule can be expressed in terms that can be directly 
related to the business, using simple, unambiguous language that’s accessible to all interested 
parties: business owner, business analyst, technical architect, and so on. It’s a constraint, in the 
sense that a business rule lays down what must or must not be the case.” (s.5) Essensen i BR 
Approach är att skriva ner alla regler som styr verksamheten, kalla dem BR, och därmed separera 
reglerna fran den dagliga verksamheten. Morgan (2002) skriver att BR ar kodad kunskap om 
foretagets eller organisationens verksamhet. En regel skrivs enligt Morgan (2002) med ett 
speciellt språk och ska begränsa verksamheten i den mening att regeln beskriver vad som far och 
inte far handa. 


3.3 Vad ar BR Approach? 


BR approach ar ett ramverk som används för att förvalta och automatisera de BR som en 
organisation har. BR Approach består av formaliserade metoder för hur BR skrivs och en 
Business Rules Repository (BRR). BRR är ett slags lagringsmagasin för organisationens alla BR. 
BR Approach består även av någon typ av Business Rules Engine (BRE) som ska automatisera 
organisationens BR. En organisation som väljer att automatisera sina BR med en BRE kan göra 
det med ett Business Rules Management System (BRMS). (von Halle & Goldberg, 2006) Mer 
om BRMS i kaptiel 2.14.1. 


3.4 BR Manifestet 


Som nämndes i kapitel 3.1 ”Kort historisk översikt” sa publicerade Business Rules Group (BRG) 
ett manifest vars syfte är att kort och koncist förklara de grundläggande principerna av BR. 
Manifestet finns tillgänglig pa svenska samt flera andra språk. Anledningen till att vi inte har 
beskriver eller förkortar Manifestet beror pa att det ar skyddat av copyright och vi inte fått 
tillstånd att använda det. Men eftersom vi tycker att dokumentet är viktigt och val beskriver 
användning av BR har vi bifogat den svenska versionen av manifestet som bilaga 5. BRG 
beskriver i manifestet sin syn på vad BR är, hur BR ska skrivas, BR konceptets innebörd och 
motivering för organisationens verksamhet med mera. Manifestet är uppbyggt av 10 stycken 
avsnitt (artiklar) som vart och ett beskriver en grundläggande princip av BR. (Business Rules 
Manifest, 2008) 
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3.5 Varför BR? 


BR utvecklas för att kunna få bukt med alla misslyckade utvecklingsprojekt av applikationer eller 
IS/IT. Yrkesverksamma ställer krav på ett nytt sätt att utveckla kravspecifikationer som 
innehåller alla behov en organisation har på en applikation eller IS. Morgan (2002) skriver att en 
anledning till att många projekt misslyckas kan vara att yrkesverksamma inte har sett tillräckligt 
allvarligt på att utveckla ordentliga kravspecifikationer inför ett utvecklingsprojekt, 
kravspecifikationer som innehåller alla regler en organisation har och som styr organisationens 
verksamhet. Essensen i BR approach är ett angreppssätt för att kunna hantera utvecklingen av 
IT/IS för en organisation och ett sätt att sammanföra och anpassa IT/IS stödet med verksamheten. 
(Morgan, 2002) Enligt BR approach så finns inte verksamheten till för att stödja IT utan IT ska 
finnas till för att stödja verksamheten. 


En organisation har, som nämndes i kapitel 1, olika regler som styr den dagliga verksamheten. 
Men dessa regler kan vara oåtkomliga eller rentav helt okända för organisationens medarbetare 
eftersom de inte finns beskrivna eller nedtecknade någonstans. Regler för verksamheten kan 
exempelvis vara inbäddade och begravda i kod inom äldre datorprogram och som organisationen 
inte har dokumenterat tillräckligt. Om regler som styr verksamheten är oåtkomliga eller okända 
för organisationens medarbetare innebär det svårigheter om reglerna behöver ändras. 
Medarbetarna kan också tro att reglerna säger något annat än vad de egentligen gör, om de inte 
har tillräcklig kunskap om dem. (von Halle, 2001) 


Det är även viktigt för en organisation att vara flexibel som svar på en föränderlig omvärld. Om 
det tillkommer nya affärsmöjligheter eller organisationens konkurrenssituation förändras kan 
organisationen snabbt behöva förändra sin egen verksamhet och sina regler för att kunna fortsätta 
vara konkurrenskraftiga. Om då reglerna för verksamheten finns begravda i programkod kan 
processen med att förnya verksamheten bli väldigt långsam. Organisationens medarbetare måste 
då gå igenom stora mängder gammal kod för att överhuvudtaget kunna hitta de regler som 
behöver förändras. Essensen i BRA är därmed också att separera reglerna från den övriga 
verksamheten så att alla inom organisationen vet att de existerar. Dessutom att externalisera 
reglerna så att alla vet vad reglerna säger, var reglerna finns och var de kommer ifrån, för att 
snabbt kunna göra förändringar i reglerna som svar på att verksamheten behöver förnyas. (von 
Halle, 2001) 


von Halle (2001) menar att det finns följande fyra principer för BR Approach: 


e Separera organisationens regler från den övriga verksamheten. 
e Externalisera reglerna så att alla vet vad reglerna säger. 


e Göra reglerna spårningsbara sa att organisationens medarbetare vet var reglerna finns och 
varifrån de kommer. 
e Positionera reglerna för förändring. 
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3.6 BR & Business Models 


Organisationer har genom tiderna använt modeller för att definiera hur de är organiserade. Detta 
har tidigare vanligtvis skett genom olika hierarkiska uppdelningar där organisationens olika 
enheter delades upp i olika delar och där de större enheterna visade sig vara uppbygga av de 
mindre i modellen. De tidigare organisationsmodellerna som kom med industrialismen bestod 
ofta av material, kapital och arbetskraft men under senare 1900-talet förändrades synen inom de 
industrialiserade länderna på hur den moderna organisationen skulle organiseras. Det räckte inte 
längre med entiteterna material, kapital och arbetskraft för att modellera en organisation i den nya 
moderna kunskapsbaserade ekonomin. Traditionellt så delades organisationen upp i olika kluster 
eller avdelningar där individer med liknande kompetenser samlogerades. Problemet med en sådan 
ordning kan exempelvis vara att det skapar en ”vi mot dem”-känsla mellan organisationens olika 
avdelningar. På senare tid har fokus flyttats mot mer processorienterade grupperingar inom 
organisationen för att förbättra förvaltningen av organisationens alla aktiviteter och öka kvaliteten 
på slutprodukten. Slutprodukten kan i bred mening vara mer än bara just en produkt. Exempelvis 
kan det vara att öka förståelsen i matematik för högstadieelever. I denna processorienterade 
organiseringen togs även externa entiteter så som kunder, leverantörer med i beräkningen för att 
modellera organisationen. (Morgan, 2002) 


Business models är vad som på svenska kan kallas verksamhets- och teknologimodeller. En 
business model kan enligt Hedman & Kalling (2002) bestå av olika nivåer, vilka också är 
relaterade till varandra. Dessa nivåer är: 


Kunder. 

Konkurrenter. 

Erbjudandenivån. 

Aktiviteter och organisationen. 

Resurser. 

Faktor och produktionsleverantörer. 

Management och organisationen vilket omfattar dynamiken i business models såsom 
kognitiva, kulturella och politiska begränsningar samt sociala restriktioner. 


SVAN SIE ON pa 


För att IT ska kunna anpassas så att det på bästa möjliga sätt ska understödja organisationens 
olika nivåer, processer och verksamhet används business model för att analysera hur IT kan 
användas som en resurs för organisationen. Kund och leverantörssystem för marknadsnivån, 
erbjudandesystem för produkter, priser och service, organisationsstödjande system för det dagliga 
arbetet samt olika resurs och kompetensinriktade system för organisationens resurser. IT bör få 
rollen att understödja människor, verksamheten och hela organisationen i dess kommunicering 
och databehandling. Eftersom varje organisation är unik kan också varje business model vara 
unik vilket medför att olika business models har olika behov av och krav på IT. IT och business 
model kan också i olika grad vara anpassade och integrerade i varandra. (Hedman & Kalling, 
2002) 
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Inom en business model används BR för att representera den logik som ligger bakom de 
verksamhets- och affärsbeslut som bygger upp den. BR är inte självständiga utan måste integreras 
med organisationens övriga representationer. BR ska integreras med andra inslag så som 
verksamhetsaktiviteter och processer, verksamhetsmål och övriga principer, andra aktörer och 
roller både mänskliga och maskinella och organisationens andra enheter som bygger upp 
verksamheten. (Morgan, 2002) Morgan (2002) skriver ”One way of looking at business rules is to 
see them as a language for business description that can be understood both by the 
businesspeople and by technologists. Ideally, the contribution made by business rules will be to 
align systems much more closely to the needs of the business they”re intended to serve.” (s.289) 


3.7 BR & Zachman framework (ramverk) 


De senaste decennierna har det gjorts försök att skapa metoder för systemutveckling för att öka 
effektivitet och produktivitet inom en organisation genom bättre och snabbare system. Ett av de 
mest förespråkade ramverken inom BR litteraturen är ”Zachman's framework” presenterat 1987 
(von Halle, 2001; Morgan, 2002; Ross, 2003; Graham, 2007). Zachman”s angreppssätt inbegriper 
sex utgångspunkter vilken var och en inkluderar synsättet från olika intressenter. De olika 
intressenterna är enligt Hay (1997): 


1. Den eller de som bedriver verksamhet inom ett visst område. 
2. De som driver organisationen. 

3. De som analyserar systemet och verksamheten. 

4. Systemdesigner. 

5. Systemutvecklaren. 

6. 


Systemet självt. 


Alla dessa sex punkter representerar en rad var i Zachmans matris. Zachman sätter sen upp sex 
kolumner som var och en representerar en av frågorna vad? hur? vem? var? när? och varför? 
(what, how, who, where, when and why). Genom dessa identifieras olika aspekter som de olika 
intressenterna bör studera. Dessa frågor representerar varsin kolumn i matrisen nedan och kan 
förklaras i följande punkter: 


Vad (what) - data som manipuleras av organisationen. 

Hur (how) - funktioner och processer. 

Var (where) - platsen för verksamheten. 

Vem (who) - nätverk av organisationer, företag och individer som är involverade. 
När (When) - tid och händelser som stimulerar verksamhets aktiviteter. 

Varför (why) - vilka motiv, regler och begränsningar som avgör hur verksamheten 
fungerar eller reagerar. (Hay, 1997 och 1998; von Halle, 2001; Morgan, 2002; Ross, 
2003) 


O UT AAs CN 


Raderna i Zachmans ramverk kan kortfattat förklaras genom följande punkter (Hay, 1997 och 
1998; von Halle, 2001; Morgan, 2002; Ross, 2003): 


- Omfång eller mål och syfte, vilket avser organisationens inriktning på verksamheten. 
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Denna del är av yttersta betydelse för att kunna utveckla ett system för organisationen. 
Verksamhetsmodellen som kan sägas vara ägarnas verksamhetsplan och beskriver vilken 
affärsverksamhet som bedrivs, vilket inkluderar strukturer, funktioner och hela 
organisationen. 

IS-modell. Denna punkt beskriver verksamheten i samma anda som föregående punkt 
men med utgångspunkt från ett IS och/eller en IS-arkitekt. 

IT-modell. En beskrivning av hur IT kan användas för att behandla IS-modellens 
specifikationer. Relationer struktureras, språk väljs och så vidare. Denna punkt innehåller 
IS-designen. 

Detaljspecifikation, vilket innebär specifikation av data, nätverk, teknik med mera. 
Funktionellt IS som är implementerat i organisationen. 


Som syns i tabellen nedan är BR av olika betydelse i olika delar av Zachmans ramverk även om 
de alltid har effekt. Speciellt i de delar som rör varför händelser inträffar kan BR få en 
framträdande roll. Men även vad det gäller regler för individers rättigheter i systemet kan de få en 
betydande roll. 


1. 


I ”Vad”-kolumnen hämtar BR sina definieringar eller snarare sitt ”vokabulär” och fångar 
upp vilket som är det aktuella verksamhetsområdet. ( von Halle. 2001, Morgan. 2002) 


”Hur”-kolumnen är en beskrivning av verksamheten och nödvändiga förändringar. ( Ross. 
2003) 


I ”Var”-kolumnen kan en verksamhetskarta utvecklas för att beskriva organisationens 
placering rent fysiskt och den interna och i viss mån även den omgivande infrastrukturen. 
( Ross. 2003) 


I ’Vem”-kolumnen behandlas organisationens och dess individers roller sa som 
skyldigheter, rättigheter och dessas inbördes relationer. Har identifieras främst rättigheter 
och begränsningar för individer vilket sedan används i BR. ( Ross. 2003) 


I ”När”-kolumnen ligger fokus på tidsplaner och händelseförlopp. ( Ross. 2003) 


I ”Varför”-kolumnen och i omfångsraden blir BR viktiga då de kan uttrycka 
verksamhetens mål och strategier genom sina formuleringar. Detta görs på ett 
lättillgängligt sätt som är lätt för organisationens medarbetare att förstå. På samma sätt 
kan BR också strukturera och förtydliga verksamhetsplanen. (Ross. 2003) I ”Varför”- 
planet blir de sista raderna mycket viktiga, med avseende på BR, då det är här BR 
framställs, implementeras, programmeras och uppdateras. 
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1 Vad 2 Hur 3 Var 4 Vem 5 När 6 Varför 
Omfång, Mål / Lista av för Lista av processer | Områden, platser, Lista av avdelningar, | Händelser och Verksamhetens 
Syfte organisationen | organisationen dar organisationen individer med mera. forlopp i mal och 

viktiga saker. utför. verkar. verksamheten. strategier. 
Verksamhets Relationer Modell över Nätverk. Modell med individers | Verksamhetens | Verksamhetsplan. 
modell mellan verksamhetens roll, kunnande och tidsschema. 

entiteter. processer. säkerhets aspekter. 
IS-modell Datamodell Dataflödesmodell | Distribuerade Individer och avd. Entiteters BR-modell. 

med länkade och applikations system. deras data, roller och | livscykel / 

entiteter. arkitektur. atkomstbegransningar. | processtruktur. 
IT-modell Dataarkitektur. | Systemdesign. Systemarkitekturen. | Granssnitt och I BR-design. 

sdkerhetsdesign. kontrollmoment. 

Detaljspecifikation | Datadesign, Applikationsdesign | Natverksarkitekturen | Säkerhets- och Tidsschema. BR-specifikation 

lagringscentral. | av delar. atkomstbegransningar. i programlogik. 
Funktionellt IS. Konvertera Korbara program. | Kommunikations Utbildad personal. Verksamhets Uppratthallande 

data. forum. handelser. av BR. 


Tabell 3.1: Zachmans ramverk 
Tabell 3.1: Zachmans ramverk ar författarnas tolkning med stöd i litteraturen. De delar där BR ar 
speciellt signifikant är markerade med grått ju mörkare gra desto djupare effekt av BR. 
(Hay, 1997 och 1998; von Halle, 2001; Morgan, 2002; Ross, 2003; Zachman Framework, 2008) 


3.8 BR & Enterprise Decision Management (EDM) 


EDM används för att underlätta och automatisera beslutsprocesser i organisationer men hur 
hänger då EDM samman med BR? EDM använder de regler som finns implementerade i BR. 
Detta gör det också lättare att uppdatera de BR som används av EDM då dessa endast behöver 


uppdateras på ett ställe i systemet. På så sätt kan analyser, strategier och beslut gentemot kunder 
avgöras snabbt och logiskt samt presenteras för användaren så denna kan tyda beslutet. BR stöder 
på detta vis indirekt beslutsprocessen i organisationer som använder BR och EDM i samverkan. 
EDM roll är att på kort tid ta en stor mängd beslut och därigenom stödja organisationen. Genom 
att operationella beslut på detta sätt tas automatiskt kan tid frigöras och läggas på andra områden. 
Detta gör att det blir möjligt att fatta snabba beslut byggda på stora mängder data, även i mindre 
organisationer med begränsade möjligheter att manuellt söka och sammanställa denna data. EDM 
gör även så att data och utfallet av beslut kan återanvändas och sparas i systemen. Logiken kan 
därmed återanvändas och behöver inte läggas in i systemet igen. (Fair Isaac Seminarium, 2008) 


3.9 Hur skrivs BR? 


Som nämndes i kapitel 3.2 ”Vad är BR?” ska en BR begränsa verksamheten i den mening att 
regeln ska beskriva vad som får och inte får hända. Med andra ord är BR begränsningar som ska 
begränsa en organisations verksamhet och beskriver något som ”måste vara”. En BR skrivs enligt 
en standardiserad modell eller språk för att underlätta för människor att skriva BR och för att 
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andra ska kunna tyda den (Ross, 2003). Morgan (2002) har preciserat fem stycken riktlinjer för 
hur en reglerskrivare bör skriva sina BR: 


1. Atomär(Atomic): Regeln är nedbruten till sin minsta beståndsdel och kan därför inte 
brytas ner mer utan att förlora viktig information som regeln måste hantera. 


UT ADIS 


Entydig(Unambiguous): Regeln ska bara ha en tydlig tolkning. 

Kompakt(Compact): En typisk regel ska skrivas kort och koncist, helst i en enda mening. 
Konsistent(Consistent): Alla reglerna är enhetliga och sammanhängande 
Kompatibla(Compatible): Reglerna använder samma termer som finns inom 


organisationens övriga verksamhet (se BR och business modells kapitel 3.6) 


Det finns flera allmänna teorier och modeller för hur en organisation bör skriva sina BR (Morgan, 
2002). Flera författare, Date, Ross, Morgan och von Halle, har angett riktlinjer för att skriva BR 
och använder olika klassificeringar för olika typer av regler (Graham, 2006). De teorier för hur 
BR skrivs som Morgan (2002) presenterar är funktionella och enkla att förstå. Morgan (2002) 
utgår ifrån fem stycken olika uppdelningar: enkel begränsning, listad begränsning, klassificering, 
beräkning och enumeration. Enligt modellen som Morgan (2002) förespråkar bygger 
regelskrivaren upp en BR som en mening med ett påstående bestående av ett subjekt och en 
begränsning. Nedan finns några exempel på hur en BR kan skrivas enligt den modell som 
Morgan (2002) föreslår. Nedanstående regler ger en fingervisning för hur några idealtyper av 


regler kan se ut. 


Enkel begränsning 
R1 


R2 


R3 


Listad begränsning 
R4 


R5 


Klassificering 


R6 


Beräkning 
R7 


En kund måste vara minst 18 år gammal. 


En beställning får inte accepteras om beställningsvärdet 
är under 30 kr. 


Ett konto får endast avslutas om kontobalansen är noll. 

En beställning får inte accepteras om något av följande är sant: 

- Bestallningen har inte betalats. 

- Bestallningen innehåller inga varor. 

En kund kan bli upphöjd från silver- till guldstatus om åtminstone ett 
av följande är sant: 


- Kunden är en VIP. 
- Kunden har en kontobalans på minst 500kr. 


En beställning definieras som en brådskande beställning om leverans 
måste ske inom mindre än tre timmar. 


Veckopris = Dagspris + 7. 


24 


Användning av och kunskap om Business Rules i svenska organisationer. 


Enumeration (Uppräkning) 
R8 En kunds status måste väljas ur följande låsta enumeration: 
-Guld, 
-Silver, 
-Bronze. 


Ovanstående BR är skrivna enligt ett logiskt och standardiserat mönster. BR R1, R2 och R3 är 
enkla begränsningar medan R4 och R5 är listade begränsningar av något som begränsas av en 
eller flera saker. R6 är en klassificering som används för att inrätta ett visst tillstånd för något. R7 
är en beräkning som används när en BR ska beräkna värden eller för att inrätta ett värde för 
något. R8 kallar Morgan (2002) för enumeration. Enumeration används för att lista olika värden 
eller tillstånd i en lista som sedan ska väljas och inrättas för något. BR, som de som är skrivna 
ovan, definierar och beskriver något som en organisation vill ska existera och som ska vägleda 
organisationen i dess verksamhet. En organisations regler är inte något oönskat utan 
organisationen använder och behöver sina regler för att kunna genomföra sin verksamhet som det 
är tänkt. Von Halle & Goldberg (2006) menar att nyttan med BR Approach är, som beskrivet i 
kapitel 3.3, att finna de regler som en organisation har och separera dem från den övriga 
verksamheten, som i listan ovan. Ovanstående regler behöver ingen specifik kompetens utan är 
enkla att läsa och förstå. En regel kan tyckas trivial att skriva ner eftersom den kan anses vara 
självklar av organisationens medarbetare. (Morgan, 2002) Men det är om alla företagets regler 
sammanförs som BRA kan tillföra organisationen något menar Morgan (2002). Ovanstående 
regler ser ut att vara hämtade från något företag som säljer olika produkter men regler kan också 
vara handlingsregler, procedurer eller utlösare (triggers) (Graham, 2006). En handlingsregel kan 
vara: om dalahästen inte är röd måste den målas röd. En procedur kan vara: Att måla något: 
skaffa resurser, besök färgbutik, köp färg, måla artikeln. Och en utlösare kan vara: om någon 
anställds lön är högre än VD:ns lön höj VD:ns lön till den högsta av alla anställdas löner. 


Nedanstående regel ger en fingervisning för hur en idealregel, enligt Morgans (2002) teorier, kan 
se ut. 


Risv En kund måste vara minst 18 år gammal. 
Rleng A customer must be at least 18 years old. 


Regler som finns inom organisationen kan ocksa vara implementerade med programkod inom 
olika datorprogram. Nedanstående exempel visar hur ovanstående regel kan se ut om den är 
skriven i javakod. 
R1 if customer.age < 18 then 
order enabled(false); 


System.out.println("Customers must be at least 18 years old "); 


Nedanstående regel är skriven med programmeringsspråket prolog som kan användas för att 
implementera BR. Den ger en fingervisning om hur en regel kan se ut när den har implementerats 
i ett program som kan användas för att uteslutande förvalta en organisations regler. 
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%R1 current year(Y):- get_time(T),convert_time(T,Y,_, , ,,_,_). 
q(a,P):- customer(P,_, Year), 
current_year(Y), 
((Y-Year) >= 18). 


Morgan skriver att organisationens medarbetare som ska fatta dagliga operativa beslut baserade 
pa organisationens BR förmodligen föredrar det första ideala regelexemplet. Dessa ideala regler 
är textbaserade och kan hanteras separat av ett specifikt verktyg. Å andra sidan föredrar 
förmodligen de systemutvecklare, som ansvarar för att organisationens IT/IS stöd ska 
överensstämma med organisationens verksamhet, det andra eller tredje regelexemplet. I det andra 
och tredje exemplet är reglerna åtminstone automatiserade. Nedanstående figur visar Morgans 
(2002) teorier om varifrån BR hämtar sin vokabulär samt hur de översätts till automatiserade BR 
i programkod. 


UML-klasser Implementering 


Bild ade. 
a t Definierar Utjamnas Oversatts 
termer för till till 
—_> 


BR Pastaende 


Datamodeller 


Formella 
BR 


4 Lagras i 
BR 
Figur 3.1: BR struktur 


Figur 3.1 är författarnas översättning av Morgans (2002) teorier (s.67). 


Definierar 
struktur för 


— 


Figur 3.1 visar att de datamodeller som finns inom organisationen, till exempel databaser eller 
andra datakällor, och BR-mallen används för att definierar hur BR skrivs. BR lagras i en databas 
samt utjämnas till de Formella BR-uttryck som kan liknas vid de som finns skrivna ovan. Dessa 
formella BR lagras också i en databas, BR Repository, samt översätts till regler som kan 
implementeras i programkod. Genom att följa pilarna baklänges från implementeringen i 
programkoden kan organisationens medlemmar urskilja var varje BR har sitt ursprung. (Morgan, 
2002) 


Morgan (2002) menar inte att det mest praktiska tillvägagångssättet är att trycka in alla regler 
som finns inom en organisation med ett formaliserat regelspråk i en BR repository. Vissa regler 
kan förvaltas på ett enklare sätt med andra verktyg. Regler för hur vissa klasser inom 
objektorienterad programmering påverkar varandra är enklare att hantera i till exempel ett 
Unified Modelling Language (UML) diagram. Regler för hur vissa datorprogram ska användas 
eller andra olika procedurbeskrivningar kan kanske förvaltas bättre på annat sätt. BR är, som vi 
nämner i kapitel 3.7 i Zachman framework, endast en del av hur en organisation genomför sin 
verksamhet, men likväl en viktig del menar Morgan (2002). Men var kan då automatiserade BR 
finnas? 
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3.10 Var kan automatiserade BR finnas? 


Morgan (2002) skriver att källor för BR kan vara: 


Dokument. 

Tacit kunskap som existerar inom organisationen. 
Automatiserade system. 

Olika affärsprotokoll. 


Det kan nämnas att tacit kunskap är en del av den interna kulturen inom en organisation och kan 
definiera hur organisationen genomför sin verksamhet ”så här har vi alltid arbetat här”. Denna 
uppsats har som beskrivits i kapitel 1.6 avgränsats till att behandla BR som kan finnas i 
automatiserade system inom organisationen. BR kan hantera olika beräkningar så väl som att 
tilldela något ett visst värde eller tillstånd Morgan, 2002. BR ämnar alltså vara ett heltäckande 
angreppssätt för att förvalta en organisations olika regler. 


3.10.1 BR & UML diagram 


Unified Modelling Language (UML) är ett standardiserat verktyg för att modellera visuella 
konstruktionsbeskrivningar av applikationer eller system. UML är ett visuellt språk som ger 
personer som analyserar och designar objektorienterade system eller applikationer en möjlighet 
att visualisera, konstruera och dokumentera artefakter av mjukvaruapplikationer och modellera 
organisationerna som ska använda sådana applikationer (Bennett et al., 2001, s.6). UML bygger 
på grafiska element såsom linjer, rektanglar och ovaler som tillsammans med vanliga ord och 
begrepp bygger upp en grafisk modell av det som ska modelleras. (Bennett et al., 2001) Nedan 
syns ett påhittat och simplifierat UML-klassdiagram som visar hur en mindre applikation ska 
hantera en kund som ska göra en beställning av en resa. 


Betalning 
-Kortnummer 
-Kortnamn 


Kund 
-Personnummer{id} : int Beställni 
förnamn 
-efternamn -Ordernr{id} : int 


-epost 
-rabatt 


-datum 


-destination 
-reseform 


Figur 3.2: Exempel pa ett UML klassdiagram 
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Vad som kan utläsas ur diagrammet ovan är bland annat att personnummer och ordernummer är 
identifierare (id) och alltså måste vara unika. Om en kund ska beställa en resa kan den kunden 
inte ha ett personnummer som redan används av en annan kund. I Sverige har alla människor ett 
unikt personnummer men genom att signera en kund en identifierare kan applikationsutvecklaren 
säkerställa att just den kunden kommer att kunna identifieras i systemet. Symbolerna 1 och + 
visar att en kund kan ha flera beställningar (*) men en beställning kan bara vara associerad till en 
kund (1) (Bennett et al., 2001). Information som inte kan utläsas ur diagrammet ovan är 
exempelvis att en person som gör en beställning måste vara minst arton år gammal. En kund har 
även en viss rabatt som beräknas på den summan som den specifika kunden har beställt resor för i 
tidigare beställningar. Rabatten är en viss procentsats som multipliceras med det fastställda priset 
för kundens aktuella beställning. Kunden får därmed ett preciserat rabatterat slutgiltigt pris. Ett 
UML klassdiagram kan alltså innehålla BR men det finns också BR som UML inte kan 
visualisera (Morgan, 2002). 


Den sista, nummer fem, av Morgans (2002) riktlinjer för hur en regelskrivare bör skriva sina BR, 
beskriver att reglerna använder samma termer som finns inom organisationens övriga 
verksamhet. Därmed är det viktigt att exempelvis BR som ska behandla kundens rabatt också 
skrivs med de ord och begrepp som redan finns representerade i UML diagrammet (Morgan, 
2002). BR för kundens rabatt kan då lyda. 


R9 En kunds rabatt måste väljas ur följande låsta enumeration: 
-Guld, 
-Silver, 
-Bronze, 
-Standard. 


R10 En kund med Guldrabbat måste fa 10% rabatt på alla beställningar. 


Reglerna ovan, R9 och R10, använder samma benämningar som finns i UML-diagrammet. 
Benämningarna Kund, Rabatt och beställning finns angivna i UML-diagrammet och ska därför 
också användas vid konstruktionen av BR. Om dessa regler för rabatt behöver ändras kan det 
innebära problem om reglerna bara finns implementerade i javakoden (Morgan, 2002). 


3.10.2 BR i programkod 


Morgan (2002) skriver att det vanligaste tillvägagångssättet för en organisation att implementera 
BR är att göra det med programkod. På sidan 25 finns redan ett exempel på hur en BR som finns 
implementerad i javakod kan se ut. Men regler kan också vara beräkningar eller olika 
klassificeringar. Hur svårt det kan vara att hitta BR i programkod visas med exemplet på javakod 
nedan. 


if(discounted_article!=0){ 
print_sum("Discounted Articles: "+discounted_article); 
float VAT =PrologConnection.ShouldpayV AT(Customer_No); 
float Delivery_Fee = DatabaseMethods.getDelivery_Fee(Customer_No); 
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print sum("Delivery Fee: "+Delivery Fee); 
float article delivery fee=discounted article+Delivery Fee; 
print_sum("VAT: "+VAT); 
float total_sum=article_delivery_fee+article_delivery_fee*(VAT/100); 
print_sum("Total sum: "+total_sum); 
DatabaseMethods.setOrder_InvoiceNo(Order_no, Invoice_No); 
DatabaseMethods.insertInvoice(Invoice_No, "", discounted_article, total sum, "", 
Delivery_Fee, VAT, Customer_No); 

}else{ 
print_sum("No order found"); 


} 


Ovanstående kod innehåller flera regler som kan vara svåra att urskilja. Ovanstående kodutdrag 
hanterar priset på en eller flera varor som en kund ska beställa. Koden kalkylerar den eventuella 
skatten (VAT), fraktkostnader (article_delivery_fee) för en rabatterad vara. Javakoden ovan 
anropar också andra delar av systemkoden som kan vara implementerad inom andra delar av 
systemet vilket är vanligt vid objektorienterad programmering (Mathiassen et al., 2001). Att 
javakoden anropar andra metoder i andra delar av informationssystemet gör att BR blir utspridda 
i systemet vilket kan försvåra för en användare att lokalisera reglerna. Morgan (2002) skriver att 
regler med fördel kan använda det språk, av variabler och metoder, som finns inom 
organisationens system. Morgan (2002) menar att följande regel 
”article_delivery_fee=discounted_article+Delivery_Fee” därmed kan skrivas som en BR genom 
att reglerskrivaren använder benämningarna ”article delivery fee”, ”discounted article” och 
”Delivery Fee” i regeln. Uppdatering av de automatiserade reglerna i programkoden kan 
underlättas om varje regel anges med en start- och en slutnotering, <Startregel för 
priskalkylering> regelkod <regelslut>. Fördelarna med att skriva BR direkt i programkoden är 
enligt Morgan (2002) att det kan gå snabbare att implementera BR direkt i koden än att 
implementera dem separat i någon form av lagringsenhet. Verksamhetens BR implementeras då 
direkt samtidigt som datorapplikationen programmeras och utvecklas. Det ska också nämnas att 
de flesta programmeringsspråk kan användas för att implementera BR, exempelvis Prolog, 
BASIC, COBOL, C++, Pascal, SQL, VBScript eller Perl för att nämna några (Graham, 2007). 


3.11 Databaser vs BR 


Databaser är och har länge varit ett av de vanligaste sätten att organisera BR. Till en början ansåg 
många, bland dem Date (2000), att BR endast styrde så att fakta som sparas i databaser inte är 
korrupta eller motsägelsefulla. Graham (2007) anser att BR reglerar så att försök till att uppdatera 
icke korrekt fakta eller data avisas. Denna syn speglar att BR styr databasen snarare än att de 
finns lagrade i densamma. BR finns i detta synsätt i regler, begränsningar, relationer och så 
vidare i databaserna snarare än att de finns uttryckta i ord. Denna syn på BR passar väl in i 
exempelvis en ingenjörsmiljö och i övriga verksamheter med stegvis, sekventiell, körning av 
procedurer (Date, 2000). Detta ger också en bild av det som kallas ”Closed World Assumption” 
(CWA). CWA betyder att en instans i databasen representerar ett sant faktum eller sann data. 
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3.11.1 Regler i databaser 


Nedan finns ett utdrag ur en databas utvecklad i SQL Server. Utdraget visar en SQL-tabell som 
ska organisera olika artiklar. Regler som kan synas i utdraget nedan är att varje artikel (article) 
består av sex variabler, artikelnumret (Article no) är nyckelidentifierare för artikeln och måste 
vara unik, detta visas genom en nyckel i övre vänstra hörnet. SQL-tabellen innehåller även en 
regel som säger att varje artikelnummer högst kan innehålla sex stycken tecken (char 6). 


Table - dbo.Article | Summary | 


[| Column Name | Data Type | = Nulls | 


re Article no ; char(6) 

rop eee a = 
J Price float O 
Bi quality char(10) IV 
[ basket_size char(10) IV 
_| eco char(6) Iv 
[ m 


Figur 3.3: Exempel på SQL tabell 


Automatiserade BR kan finnas på en mängd olika platser inom en organisations olika system. Om 
organisationens medarbetare förlorar kontroll och översyn över alla dess regler blir det problem 
om någon av dem blivit inaktuell och behöver ändras. Reglerna som finns implementerade i 
databasen ovan kan skrivas som BR för att sedan också kunna hanteras separat. 


3.12 Hur bör BR implementeras? 


Von Halle (2006) beskriver hur implementeringen av BR bör struktureras. Hon börjar med att 
trycka på vikten av en god systemdesign och systemarkitektur och i detta fall BR-arkitektur och 
design. Först sätts mål och krav upp mot vilka arbetet fokuseras. Dessa mål och krav innehåller 
vad BR ska tillföra organisationen och vilka uppgifter de ska stödja. Men arbetet måste också 
inkludera de befintliga eller tillkommande system med vilka BR ska samordnas. Alla dessa 
aspekter sätter upp begränsningar för hur BR kan implementeras och samordning med andra 
system blir ett centraltbegrepp. (von Halle, 2006) 


Von Halle (2006) sätter upp fyra viktiga steg för att designa en god arkitektur: 
e Definiera kvalitetsaspekter som prestanda, lätt att underhålla och så vidare. 
e Rangordna kvalitetskraven, detta underlättar om konflikter uppstår. 
e Försök att finna flera designalternativ. 
e Avgör vilket designalternativ som är att föredra. 


En regelbaserad grund, BR-repository, bör väljas. Genom denna kommer utvecklare enkelt att 
förstå resultaten men även hur de uppstår. Om man istället väljer att implementera BR i kod 
(Java, SQL m.fl.) blir de svåra att finna och tyda även för tränade systemutvecklare. Det senare 
gör också att BR blir svåra och tidskrävande att underhålla. Von Halle (2001) hävdar att det är 
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tidsbesparande i det långa loppet även om det är tidskrävande att konstruera ett BR-repository. 
Hon menar att tiden tjänas in när BR ska uppdateras då dessa är enkla att finna och inte är 
begravda i till exempel javakod. Dagens organisationer har inte längre råd att förlora tid genom 
att ha otillgängliga system där uppdateringar i mjöligaste mån undviks. Organisationernas system 
måste istället vara flexibla och lättolkade. En implementering av en tydlig BR konstruktion gör 
det också möjligt för både verksamhets och regelanalytiker att delta genom hela 
utvecklingsprocessen. BR-utvecklaren skall ha ett nära samarbete med de övriga 
systemutvecklarna så att de tillsammans kan konstruera system och gränssnitt som möjliggör 
samverkan mellan de olika delarna. Ett javaobjekt kan till exempel anropa en BR genom ett 
gränssnitt för att testa om ett numeriskt värde är valid. Reglerna skall också implementeras så att 
det finns enskilda regler som styr svar från systemet likaväl som det finns regelkluster som i 
samverkan ger svar. Det rekommenderas att använda ett BRMS. (von Halle, 2006) 


3.13 Hur kan automatiserade BR hittas? 


Att hitta en organisations olika BR kan vara en tidsödande process. För att kunna hitta viktiga 
regler som en organisation innehar och som styr dess verksamhet kan organisationens 
medarbetare behöva genomföra grundliga analyser av systemens programkod. BR kan finnas 
gömda i olika databaser eller i gamla system som funnits i bruk inom organisationen en längre tid 
utan några grundligt genomförda systembesiktningar. Dokumentationen om vad organisationens 
olika system gör och inte gör kan vara otillräcklig eller till och med saknas. (Xinyu et al., 2004) 


3.13.1 Automatiserad regelidentifiering. 


En dator med rätt applikation kan användas till att förvalta en organisations regler men den kan 
även användas för att söka igenom programkod för att identifiera regler. Detta kallas automatisk 
regleridentifiering. Morgan (2002) skriver att det finns verktyg som är designande för att hitta 
regler. Dessa verktyg kan söka och finna regelunderlag i organisationens system exempelvis i 
databaser eller javakod och annan programkod. Dessa verktyg kan bara användas då 
organisationens olika system lämpar sig för detta. Men att endast förlita sig på automatiserad 
regleridentifiering går inte idag. Tillkortakommanden av de automatiserade 
regelidentifieringsverktygen medför att det enda sättet att hitta alla viktiga regler är att dyka ner i 
organisationens programkod och analysera den manuellt menar Morgan (2002). Olika 
organisationer kan använda olika tillvägagångssätt för att hitta regler som är implementerade i 
deras system. Trots det finns det metoder tillgängliga som enligt utvecklarna ska underlätta 
identifiering av BR i system och programkod (Chia-Chu & Bayrak, 2006; Ali et al., 2005). 


3.13.2 Data mining 


Genom data mining söker man igenom organisationens system efter data. Men det behövs filter 
för att hitta den data som söks och avskilja all den data som inte är intressant. Ytterligare ett steg 
är att formatera data så att den kan användas i tänkt syfte i exempelvis en databas. Genom data 
mining kan data sökas för att stödja beslut i ett EDM men data mining kan även användas för att 
extrahera regler att implementera och uppdatera i organisationens BR. Data mining kan användas 
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för att hitta kunders köpmönster då systemet snabbt kan hitta fakta om hur kunderna beter sig och 
vilka köp de gör. Systemet kan jämföra kundernas beteende, presentera data i diagram och 
tabeller. Även grunden för anpassning och skapande av BR kan ske genom den utvunna data. 
Data mining nämns ofta och kan vara speciellt effektivt vid kundanpassad reklam eller 
kundanpassade erbjudanden och kampanjer. (Morgan, 2002) 


3.14 Hur kan BR förvaltas? 


BR-användning eller BR-förvaltning beskrivs som stöd för att göra beslut snabba, effektiva och 
enkla att förstå. Det beskrivs även som ett kostnadseffektivt verktyg som implementeras för att 
stödja användarna i en allt mer informationsbaserad omvärld. Beslut ska snabbt kunna fattas och 
vilken data som måste finnas eller hämtas från systemen ska vara klart utan att användaren 
behöver specificera alla dessa detaljer. Systemen ska kunna användas och underhållas av 
användare utan några djupa programmeringskunskaper och det ska kunna anropas från en mängd 
olika applikationer. Business Rule Management (BRM) anammas av organisationer för att frigöra 
BR från programkod och göra den tillgänglig för dessa applikationer samt göra BR lättare att 
tolka och uppdatera. (Ilog, 2008; Date, 2000) 


Spreeuwenberg som ar en av de frekvent återkommande artikelf6rfattarna pa BR-community 
uttrycker det som att BRM är ett område som organisationer behöver lägga stor vikt vid om de 
vill halla sig konkurrenskraftiga, flexibla och innovativa (Spreeuwenberg, BR-community, 2008). 


IS och IT har genom aren tagit över förvaltningen av BR genom att automatisera dem. Det ar 
numera systemen som ansvarar för datahdmtning och även i hög grad tolkning av data. Det är 
även en trend att systemens uppgift och programmeringen av desamma har övergått fran att vara 
processstyrda till att bli deklarativt styrda. Det senare deklarativa sättet later systemet göra jobbet 
och användaren ställa frågorna. Vidare leder detta till att det språk användaren använder 
gentemot systemet liknar mer ett naturligt språk till exempel engelska eller svenska. Målet är 
enligt Date (2000) att användaren talar om för systemet vilken sorts applikation som behövs och 
systemet kompilerar koden. Det är dock fortfarande så att den mesta programmeringen är gjord i 
processinriktad kod, men BR är ett sätt att ta steget mot automatiserade verksamhetsprocesser. 
(Date, 2000; Graham, 2007) 


Att genom BR-teknik automatisera processer kan enligt många (Date, 2000; Graham 2007) 
beskrivas i fyra steg: 


1. Steg ett är att finna och utvinna BR ur processer och kod. 

2. Steg två, att uttrycka eller beskriva BR deklarativt, här ger bland annat Morgans (2007) 
ramverk ett gott stöd. Med deklarativt menas att regler uttrycks istället för att kodas. Som 
exempel kan vi ge: ”Om en kund är student ge 20 % rabatt”. 

3. Tredje steget är att köra reglerna på en plattform eller genom en applikation som kan 
exekvera BR, en BRE (Business Rules Engine). 

4. Det fjärde och sista steget är att låta användarna redigera och använda BR. (Date, 2000; 
Graham, 2007; Oracle 2008) Det är även vanligt att använda ett BRMS (Business Rule 
Management System) vilket beskrivs nedan. 
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3.14.1 Grunderna i ett BRMS 


Ett sätt att förvalta BR är Business Rule Management (BRM) och BRMS. Ett BRMS är enligt 
Graham (2007) ett ekonomiskt sätt att förvalta BR. BRMS består av flera delar, som vi strax 
kommer att beskriva utförligare, men det behövs även engagemang och hängivenhet att författa, 
underhålla och utvinna reglerna. BRMS innehåller främst följande ingredienser och förpliktelser: 


e Att underhålla och lagra BR som representerar regler och procedurer i en verksamhet i ett 
Business Rules Repository (BRR). Ett BRR är en lagringsplats, ett magasin, för BR 
varifrån de kan hämtas och användas. Ett exempel på detta kan vara en databas. (Date, 
2000) 

e Att integrera BR i verksamhetens applikationer så att BR kan användas i beslutsfattandet 
så väl som i den dagliga verksamheten. (Graham, 2007) 

e Formulera oberoende regler som kan användas sammanlänkade eller var för sig. Detta för 
att reglerna ska kunna användas av olika applikationer och i olika kedjor men även för att 
de enkelt ska kunna uppdateras i separata delar. Att på detta sätt dela BR över 
applikationer och genom olika delar av verksamheten kan liknas vid hur data delas genom 
en databas. Det finns därför ingen anledning att hämta BR från BRR för att lagra den i 
internminnet och utan de körs direkt. Detta sätt att formulera deklarativa och oberoende 
regler gör det möjligt att undvika hierarkiska och strikt beroende regelhierarkier.(Graham, 
2007; Date, 2000) 

e Att tillåta både verksamhetsanalytiker och användare att tolka, skapa och underhålla BR 
med ett minimum av träning eller utbildning (Graham, 2007). Det ska även ges direkt 
feedback vid uppdatering så att regler inte av misstag ändras och blir falska, det vill säga 
att utfallet ändras från det som var den ursprungliga intentionen (Date, 2000). 

e Automatiserande av BR som stöd och för att underlätta verksamhetens processer 
(Graham, 2007). 

e Till sist är det en verklig utmaning att skapa en överblickbar kommunikation mellan 
applikationer och en i slutändan naturlig, logisk och lättförstålig dialog med användarna 
(Graham, 2007). 


3.15 Vem eller vilka har ansvaret för BR? 


Även om vi finner att BR främst tillhör den sjätte kolumnen, why i Zachmans ramverk, så 
påverkas BR även av de andra fem delarna. I första kolumnen där strategier och mål för 
verksamheten avgörs läggs grunden för BR. I andra kolumnen finner vi de processer och 
funktioner som BR är tänkt att stödja. I den tredje kolumnen finner vi de roller - organisationen, 
beslutsfattare, medarbetare med mera - som BR är tänkt att stödja. Det är därför viktigt att 
involvera de personer och avdelningar inom organisationen som använder och formulerar regler, 
mål och strategier. Det slutliga ansvaret för förvaltning av BR läggs på den eller de BR-analytiker 
(denna roll förklaras närmare i nästa stycke) som har ansvaret för förvaltningen av reglerna vilket 
inbegriper att utveckla, formatera och implementera BR. Men det är viktigt att få all fakta från de 
olika grupperna och att de olika rollinnehavarna förstår och kan tolka de BR som de använder. 
BR-analytikern, eller arkitekten om man så vill, skall också föra ett nära samarbete med övriga 
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systemarkitekter vid framställning av gränssnitt, användarfunktionalitet med mera. (von Halle & 
Goldberg, 2006) 


3.15.1 Tre roller i förvaltningen av BR 


För att förtydliga resonemanget från ovan kan vi nämna att vid exempelvis framställning av BR 
gällande löner bör löneavdelningen medverka, vid förvaltning av BR mot kundrelationer bör 
säljavdelning och kundserviceavdelning ingå och så vidare. Inom den grupp eller grupper som tar 
fram och formulerar BR är det lämpligt att välja någon ansvarig för underhåll och uppdatering av 
varje BR, en BR-förvaltare eller en BR-Steward. Denne BR-Stewards uppgift är att se till att BR 
är i linje med rådande policy, mål och strategier i organisationen och att upprätta och uppdatera 
denna BR. Men Stewarden skall även till se att BR sparas och dokumenteras på rätt ställe, 
exempelvis i ett BRR, och att en BR elimineras om den skulle bli inaktuell. Stewarden har också 
till uppgift att se till så att BR formateras på samma sätt inom organisationens olika avdelningar 
och att BR dateras, namnges och görs spårbar. Det finns inom detta område ytterligare roller som 
bör nämnas och en av dessa är BR-Analyst eller på svenska BR-analytiker, som nämndes ovan. 
BR-analytikern har en mer övergripande roll och har som uppgift att se till att BR stödjer 
systemen och att de uppfyller de krav och mål som de skall representera, var för sig eller i 
kombination. BR-analytikern skall också se till att reglerna används och föreslå sådana som bör 
raderas eller uppdateras. Analytikern ska kunna förutse vilken effekt en BR-förändring får innan 
den implementeras eller föreslås. Han/hon står även för att utvinna BR ur dokument, kod med 
mera, för att föreslå eller lägga grund för BR konstruktion. Slutligen bör det nämnas att BR 
analytikerns uppgift också innefattar att se till att inte motstridiga BR existerar och att inte 
dubbletter förekommer. Med det senare menas att samma BR anropas av olika processer eller 
system utan att förekomma på flera ställen i systemet. Detta leder oss in på den tredje rollen vi 
vill nämna, nämligen BRR-Administrator eller Administratören. BRR-administratören har som 
uppgift att se till att det finns konsekvens mellan olika BRR och att kontrollera och underhålla 
dessa. Administratören fördelar rättigheter för åtkomst och ser till att integriteten inom BR 
upprätthålls. Denne har också det slutliga ansvaret över att BR formatet är konsekvent och att en 
god BR identifiering upprätthålls. (Wall et al., 2001) 


3.16 Rule Maturity Model & Software Process Improvement (SPI) 


Idag finns det flera olika ramverk inom området för SPI som med hjälp av olika riktlinjer kan 
användas för att bestämma en nivå av mognad på en organisations verksamhet ur olika 
synvinklar. (Humphrey, 2007) von Halle (2007) beskriver Rule Maturity Model (RMM) vilken 
framställer en organisations mognad ur BRs synvinkel. Principen bakom SPI, och många 
ramverk inom SPI, är att en produkts kvalitet influeras av kvaliteten på den process som har 
använts för att utveckla den. Användning av SPI förlitar sig på integrering av många tekniska, 
organisatoriska och metodologiska problem i olika modeller. RMM, vilken beskrivs nedan, är 
besläktad med andra modeller inom SPI. 


34 


Användning av och kunskap om Business Rules i svenska organisationer. 


3.16.1 Rule Maturity Model (RMM) 


Rule Maturity Model (RMM) beskriver en organisations mognad med avseende på BR. Skalan i 
modellen är graderad från noll till fem där noll betyder att organisationens medlemmar är 
omedvetna om BR. Nivå fem betyder att organisationen använder BR fullt ut och organisationens 
medlemmar är fullt medvetna om dess betydelse. Nivåerna beskrivs översiktligt i punktlistan 
nedan medan tabellen nedan visar BR:s effekt i olika stadier. Det är dock en process för 
organisationen att gå från grad noll till fem i RMM. En organisation ska inte försöka ta genvägar 
och försöka hoppa över steg i modellen utan BR-mognaden bygger på en gradvis uppgradering i 
nivåerna. Varje steg beskriver en signifikant förändring i organisationens kultur och förmåga att 
integrera BR. Många av dagens organisationers IT-projekt hamnar på nivå noll, vilket betyder att 
organisationen är omedveten om BR och deras effekt på projektet. BR finns då gömda i 
manualer, dokument, programkod med mera där de också med stor sannolikhet kan gå förlorade. 
Med en BR-mognad på nivå noll vet ingen inom organisationen egentligen var, när eller hur de 
ska börja leta efter en regel eller hur lång tid det tar att finna och uppdatera den. Medarbetare i 
organisationer som befinner sig på nivå noll använder sig av BR utan att egentligen veta vilka BR 
som styr, var de finns eller vilken effekt BR har. Medarbetarna ser endast resultatet av en BR och 
att ändra BR i en organisation med den nivån av BR-mognad kan bli ytterst kostsamt. På nivå ett 
används vissa BR och de implementeras också i systemen men de finns fortfarande lagrade i 
dokument, manualer med mera. Här lägger organisationen inte heller ner någon betydande tid 
eller pengar på att strukturera sina BR. Det är först på nivå två som organisationen börjar 
utveckla metoder för att finna och lagra BR. De lagrade BR kan dock fortfarande inte användas 
av andra system genom automatisering, men BR har nu fått en definierad lagringsplats, ”BRR”, i 
organisationens IT-system. På tredje nivån har organisationen strukturerade BR och 
uppdateringsbarheten har väsentligt ökat från tidigare nivåer. Det börjar också skönjas ett system 
av hur BR utvecklas vilket gör att de kan delas mellan avdelningar eller projekt. BR kan nu 
testas, skapas eller uppdateras utan hjälp av teknisk personal, det vill säga användare och/eller 
applikationer kan direkt tyda BR. På nivå fyra och fem kan BR användas fullt ut. Genom 
automatiserad exekvering av BR kan organisationen ta snabba beslut samt även göra 
förutsägelser av hur de påverkar framtiden (von Halle, 2001; von Halle, 2006; von Halle, 2007; 
Debevoise, 2007). RMM kan användas för att definiera vilken nivå av BR mognad som en 
organisation har, se tabellen nedan. 
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Beskrivning av de olika mognadsnivåerna som redovisas i tabellen nedan. 
e Niva 0 -här finns ingen kunskap om BR. 


e Niva 1 - kunskapen om regler har vaknat. 
e Niva 2 - reglerna börjar bli mer funktionella och strukturerade. 
e Niva 3 - konsekvens, gruppering och struktur av BR skapas. 
e Nivå 4 - BR kan förutsägas och även förutsägelser om en nära framtid kan göras. 
e Niva 5 - förvaltning av BR och förutsägelser av framtiden. 
( von Halle, 2007. Debevoise, 2007) 
Rule Maturity Model. 
Nivå 0 Nivå 1 Nivå 2 Nivå 3 Nivå 4 Nivå 5 
Omedvetenhet Vetskap Agility Konsekvens Förutsebarhet Förvaltning 
Minimum Värde för verksamheten Max 
Höga Lägre Svag förmåga att | Förmåga att Effekten av Effekten av 
förändrings- förändrings- förutse förutse förändringar är förändringar är 
kostnader. kostnader. förändringars förändringars förutsebar. förutsebar, 
Ingen förmåga | Fortsatt dålig effekt. Regler effekt är organisationen 
att förutse förmåga att och processer förbättrad. har god integritet. 
förändringars förutse effekten | möjliga att Automatiserad 
effekt. av förändringar. | analysera. regelanalys som 
Analys av regler reducerar 
är möjligt men kostnader. 
innebär vanligen 
manuellt arbete. 
Omogen Teknologiskt tillstånd Mogen 
BR begravt i BR är avskilt BR är BR är separerat BR är definierat | BR styrning är 
kod, dokument | från andra strukturerat från övriga på speciell integrerat i 
eller tacit system eller genom mallar, systemet men kan | lagringsplats och | verksamhets- 
kunskap. lagrade på analys och köras och kan relateras till | processerna. 
speciell plats. design. BRMS anropas från de business värde. 
implementeras. övriga systemen. 
Minimum Verksamhetskontroll Max 
Diskussioner BR analyseras Analysera, Scenarios skapas | BR påverkan En flexibel och 
förs om att och testas. IT definiera och för att testa kan förutses och | lärande 
utvinna BR från | spårar regler i förändra automatiserade infrastrukturen organisation har 
olika delar av systemen. processer och BR | BR med andra delar | börjat och 
verksamheten. strukturen. av systemet upprätthålls. 
fungerar. 
BR i projekt BR delas mellan projekt BR delas genom organisationen 


Tabell 3.2: Författarnas tolkning av von Halles ” Rule Maturity Model” 


3.17 BR & kunskapshantering 


Det finns kritik mot BR när det gäller förvaltningen av tacit kunskap. Tacit kunskap är sådan 
kunskap som människor har i huvudet och alltså är svår att dokumentera. Kritiken bygger på att 
det är svårt att genom kodade regler stödja tacit kunskap. Det är möjligt att extrahera BR ur 
kunskap men det finns inte några bra sätt att koda ”know-how”, till exempel en hantverkares 
skicklighet och kunskaper. Andra tacita kunskaper är kunskap som kan kallas ”know-who”. Detta 
innefattar kunskap som att veta vem eller vilka som kan utföra vissa uppgifter eller kan vara 
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behjälplig på andra vis. All denna tacita kunskap är svår att förvalta med stöd av BR. Individer 
kan också vara ovilliga att dela med sig av sin kunskap då denna kan ge individen en viss makt 
inom organisationen vilket Focault (1980) benämner ”power of knowledge”.(Johnson et al., 
2002) 


Det kan vara en utmaning för de som är ansvariga för kunskapshantering att omvandla kunskap 
från tacit till explicit (Sveiby, 1996), liksom att sedan implementera den i BR. Normer och regler 
som ingår i en organisations kultur är också svåra att implementera i BR. Även om de har en 
stark effekt på en organisation är de oftast inte nedtecknade i några dokument eller manualer, de 
räknas därmed som tacit kunskap och styr utan att vara uttalade eller utan att individerna följer 
dem medvetet vilket gör det än svårare att formulera dem som BR. Det kan även ingå i en 
individs yrkesskicklighet att kunna avgör hur han eller hon ska bemöta problem eller välja rätt 
verktyg till rätt tillfälle. De ovan nämnda exemplen kan vara mycket situationsanpassade eller 
kulturella och går därför inte att koda som BR. (Sveiby, 1996) 


Sveiby (1996) skriver att även traditioner är svåra att formulera som explicit kunskap, han 
uttrycker det: 


”Tradition is a dynamic unarticulated process by which a process-of- 
knowing is transfered between individuals, it has no purpose, no written 
rules and no power centre.” (Sveiby, 1996, s.382) 


Traditioner följs och överförs mellan individer utan att vara nedtecknade eller uttalad i 
organisationen och Sveidby (1996) menar att det därför inte går att överföra dessa till explicit 
information. Det är därför mycket svårt att i BR ta hänsyn till dessa traditioner och svårigheterna 
är som nämnts ovan, likartade när det gäller normer och kultur. 
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4. Tillvägagångssätt 


Detta kapitel beskriver hur vi gått tillväga för att finna de fakta, data och de resultat vi redovisar. 
De teorier och metoder som vi tagit stöd av redovisas här. Under vår inledande litteraturstudie 
fann vi att BR inte är så väl utforskat i Sverige (BR-community, 2008). Därför har vi till viss del 
gjort en explorativ och deskriptiv studie. Att vi skriver explorativt och deskriptivt beror på att vi 
har undersökt vissa frågor direkt i en kontext snarare än att först söka efter svar i litteratur och 
sedan beskriva detta. Vi har använt och studerat befintliga undersökningar, annan litteratur och 
tidigare utvunnen kunskap för att kunna beskriva de fakta, data och de resultat vi redovisar. 
(Kvale, 1996; Yin, 2003) 


4.1 Urval 


De organisationer som passar vårt syfte är organisationer som dagligen måste genomföra 
operativa beslut. Som beskrevs i inledningen har alla organisationer regler som vägleder 
organisationens medarbetare i den dagliga verksamheten. Att finna organisationer som faller 
inom vår avgränsning och passar vårt syfte var därför inte särskilt svårt. Efter vår inledande e- 
postundersökning hos mjukvarutillverkare och vår litteraturgranskning började arbetet med att 
finna organisationer att undersöka närmare. Vi ville finna olika organisationer inom olika 
områden där vi kunde utföra våra kvalitativt inriktade studier. Genom att på detta sätt skilja ut 
relevanta organisationer som agerar inom olika områden hoppas vi kunna uppnå en viss 
generaliserbarhet. För att uppnå en generaliserbarhet behöver man selektera ut en eller flera 
organisationer eller case som fungerar som goda representanter för många liknande 
organisationer eller case (Seale, 1999). Vi valde därför ut tre olika grupper av organisationer som 
vi ville undersöka. Kommunal verksamhet och tillverkningsindustri var två av valen. Dessa har 
organisationer som är likartade och finns över hela Sverige och ger därför en god grund till 
generalisering. Den tredje typen av organisation, statlig myndighet, valdes på grund av dess 
regeltäthet och även de har en likartad karaktär över hela landet, att välja organisationer som 
passar inom dessa kriterier rekommenderas av Seale (1999). Vi undersökte BR i dessa 
organisationer för att få svar på våra forskningsfrågor. Vi ville genom studier i dessa 
organisationers system, eller delar därav, kunna se hur BR förvaltas och är implementerade. Men 
vi ville också genomföra intervjuer eller e-postfrågorer hos våra fallorganisationer. 


Lämpliga intervjupersoner inom dessa organisationer är personer som varje dag kommer i 
kontakt med vad vi kallar BR. Dessa personer utför, förvaltar, i sitt dagliga arbete operativa 
beslut baserade på BR och kan beskriva hur BR verkligen förvaltas inom organisationen. Dessa 
personer har också den mest detaljerade informationen av hur det arbetet går till. Vi hade för 
avsikt att intervjua minst två personer som förvaltar BR inom två olika organisationer och 
verksamheter. Vi försökte hitta rätt personer genom att först ringa upp organisationen för att via 
frågor och samtal med olika personer i organisationen så småningom få kontakt med rätt 
personer. Om organisationen inte har någon policy för hur regler och BR förvaltas kan det bli 
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svårare att hitta de personer som innehar kunskapen om BR i dessa organisationer. För att 
försäkra oss om personens lämplighet för vår forskning genomfördes först en telefonintervju. Om 
inte den första kontakten var den vi sökte kunde denne hänvisa oss till en lämplig person. Ett e- 
post skickades till intervjupersonerna där vi angav vilka vi var och syftet med vår uppsats (Bilaga 
2). Detta kom också att förbereda intervjupersonerna på vilket eller vilka ämnen som skulle tas 


upp. 


4.1.1 Därför valdes boverket 


Boverket valdes som fallorganisation eftersom det är en statlig myndighet och även har många 
regler att handskas med i sin dagliga verksamhet. Boverket är centraliserat till en enhet som finns 
i Karlskrona vilket medför att stora delar av verksamheten finns representerade där. Att de har sin 
verksamhet koncentrerad till ett ställe gjorde det enklare för oss att genomföra vår stuide hos 
dem. 


4.1.2 Därför valdes kommunerna 


Kommunerna valdes som fallorganisationer eftersom de är organisationer som är regelintensiva, i 
den mening att det finns regler som styr verksamheten inom alla områden. I en organisation med 
många avdelningar eller förvaltningar finns det BR som är lika för de olika delarna och därför är 
möjliga att implementera centralt för att sedan användas lokalt i organisationen (von Halle, 
2001). Vi valde dessutom att kontakta en relativt liten kommun och en relativt stor kommun. 
Detta för att kunna få en bred bild av svenska kommuner och deras BR-förvaltning. Att valet av 
dessa hamnade inom dessa gränser kontrollerades genom statistiska centralbyrån (SCB, 2008). 


4.1.3 Därför valdes ITT, Flygt. 


Flygt var ett bra val då de är representativa för svensk verkstadsindustri. Men de valdes även för 
att de är av en storlek som gör att det finns många regler som styr verksamheten. Det är också 
intressant att Flygt liksom många andra tillverkningsföretag inte har IT och IS som sina främsta 
mål utan dessa är till för att stödja den övriga organisationen. 


4.2 Intervjuer 


Vi valde att använda intervjuer som insamlingsmetod. Kvale (1996) skriver att intervjuer används 
för att utveckla detaljerad empirisk data. Anledningen till att vi valde ett kvalitativt 
tillvägagångssätt, som intervjuer innebär, är att vi inte ville förhindra att alternativa idéer och 
synsätt skulle uppstå. Vi kunde med intervjun som metod få en direkt kontakt med våra 
intervjupersoner vilket hade varit omöjligt om vi hade valt att skicka ut e-postfrågor. Intervjuer 
gjorde det också möjligt för oss att ställa följdfrågor och be intervjupersonerna att förtydliga sig. 
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Vi kunde genom intervjuer lättare komma till botten med frågor med avseende på intressanta 
aspekter, beskrivningar och åsikter som våra intervjupersoner delade med sig av. Detta 
explorativa tillvägagångssätt passade vårt syfte eftersom vi har valt att undersöka ett område som 
till viss del är outforskat. Det var viktigt för undersökningen att vi som intervjuare var öppna för 
nya oväntade insikter i problemområdet. Dessa nya vinklingar kan komma upp under samtal med 
intervjupersoner och ge en mer nyanserad bild av de frågor som ställs. Genom att låta 
intervjupersonerna utveckla sina egna resonemang kunde vi minimera risken för att våra egna 
tankar om problemområdet skulle påverka intervjun. 


Kavle (1996) nämner två olika tillvägagångssätt för att genomföra intervjuer. En väg att gå är att 
strukturera intervjuerna och förbereda frågorna. Intervjuaren kan på det sättet försäkra sig om att 
få svar på några förutbestämda frågor. Det andra alternativet är att inte förbereda strukturerade 
frågor utan låta intervjun utvecklas fritt. I den första av dessa metoder benämns intervjuaren som 
gruvbrytare. I rollen som gruvbrytare försöker intervjuaren utvinna data ur informationen som 
ges. Det kan vara kvantitativ data för verifiering eller att finna essentiell data. I båda fallen söker 
intervjuaren att klarlägga och tydliggöra data genom en strukturerad intervju. Vid användning av 
den andra metoden kan intervjuaren liknas vid en vagabond. Vagabonden låter intervjun leda 
sökandet efter data och istället för att strukturera intervjun leder frågor och svar till nya frågor. 
Med stöd av detta utvecklade vi vår intervjuguide och försökte strukturera våra frågor så att vi 
kunde finna de svar vi sökte. Vi använde alltså övervägande gruvbrytarens tillvägagångssätt. Men 
då vi även kom att låta intervjupersonen fritt beskriva vissa aspekter tog vi även till en mindre del 
rollen som vagabonden. Att vi strukturerade intervjuerna på detta sätt berodde på att vi ville ha 
svar på vissa speciella frågor men även få den intervjuades egna aspekter. (Kvale, 1996) 


4.2.1 Intervjuguide 


För att underlätta intervjuprocessen utarbetade vi en intervjuguide som vägledde oss under 
intervjuerna (Bilaga 1). Intervjuguiden används för att rama in våra intervjuer inom det område 
som denna uppsats ämnar undersöka. Vi ville att de frågor och ämnesområden som skulle täckas 
in under varje intervju var nedskrivna i vår intervjuguide för att försäkra oss om att alla intervjuer 
skulle ge den information som vi hade tänkt oss. Intervjuguiden används också för att samma 
frågor och ämnesområden ska belysas under samtliga intervjuer. 


Intervjuguiden är indelad i tre olika avsnitt. Inledningsvis och innan den egentliga intervjun 
påbörjas får intervjupersonen en muntlig introduktion där vi berättar vilka vi är, var vi kommer 
ifrån samt syftet med uppsatsen. Anledningen till detta är att kvalitén på svaren ökar genom att 
intervjupersonen får veta vårt syfte och därmed minskas den tid som ges åt sådant som inte är av 
intresse för vår uppsats. Intervjupersonen blev också tillfrågad om det är i sin ordning att vi gör 
en ljudinspelning av intervjun. Att berätta vilka vi är och var vi kommer ifrån ger 
intervjupersonerna en förståelse för varför vi genomför intervjuerna, vilket kan få dem att känna 
sig tryggare i intervjusituationen. Innan varje intervju påbörjades poängterade vi att deltagande är 
frivilligt och erbjöd intervjupersonerna anonymitet. Detta är viktigt för att intervjupersonerna ska 
känna sig trygga i intervjusituationen och inte oroa sig för sin integritet. Intervjuguiden blev en 
karta vilken ledde oss genom de två intervjuerna. (Kvale, 1996) 
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Nästa avsnitt i intervjuguiden ägnas åt att samla in relevant information om respektive 
intervjuperson. I detta avsnitt samlar vi bland annat in intervjupersonernas namn, ålder och hur 
länge de har arbetat inom respektive organisation. Information om intervjupersonens 
arbetsuppgifter och arbetssituation är även en viktig del av intervjun. Dessa beskriver 
respondenten bäst med egna ord, vilket också ger en mjuk start på intervjun. (Kvale, 1996; 
Bryman, 2002) 


Det tredje avsnittet i intervjuguiden innehåller de egentliga intervjufrågorna. Vi valde att använda 
oss av både öppna och slutna frågor i intervjuerna. Öppna frågor användes när vi ville att 
intervjupersonen skulle svara så beskrivande och målande som möjligt. Öppna frågor kan ge 
målande och fylliga beskrivningar men de kan också medföra att kodningen av intervjumaterialet 
blir mer tidskrävande. Slutna frågor användes då vi inte ville ha målande beskrivningar och då vi 
ville begränsa svaren. (Bryman, 2002) 


Engqvist (1997) behandlar det faktum att intervjuaren omedvetet eller medvetet sänder signaler 
till den som blir intervjuad. Signalerna kan bestå av kroppsspråk eller intervjuarens tonfall. Om 
intervjuaren är medveten om att dessa signaler existerar kan dess påverkan minskas men det är 
omöjligt att helt undvika dem. Vi försökte minimera sådan påverkan efter bästa förmåga men 
som Engqvist (1997) nämner är vi inte maskiner och kan inte helt undvika att sända signaler. 
Intervjupersoner kan också påverkas att svara så som de tror att intervjuaren vill. Att på detta sätt 
försöka tillfredsställa intervjuaren förekommer oftast då den intervjuade på något sätt är i 
beroendeställning till intervjuaren. Det är därför inte lämpligt att en chef intervjuar de han eller 
hon är chef för, speciellt inte angående känsliga ämnen på arbetsplatsen. Vi hade inte denna 
ställning vid våra intervjuer men vi tänkte ändå på att försöka undvika att påverka de intervjuade 
på detta sätt. (Bryman, 2002) 


4.2.2 Öppna och slutna frågor 


Vi visste att öppna frågor tar längre tid att svara på än slutna och att kodningen och analysering 
av öppna frågor är mer tidskrävande. Men vi lade inte vikten på att göra en stor mängd intervjuer 
utan ville istället göra några få med högre kvalité. Därför beslöt vi oss för att använda 
semistrukturerade intervjuer. För att få en högre kvalité och ett bättre djup lät vi de intervjuade 
tala fritt och gav dem även följdfrågor för att få målande beskrivningar. De svar vi fick på de 
slutna frågorna gav oss möjlighet att jämföra de svar som de olika intervjupersonerna gav, medan 
de målande beskrivningarna gav oss en bättre insikt i intervjupersonens organisation och 
arbetssituation. Om vi hade använt för stor del öppna frågor hade det kunnat bli tidskrävande och 
intervjupersonen hade kunnat uppleva det som tröttande att ge många detaljerade svar. Bryman 
(2002) säger också att för att få ett bra flyt och uppriktiga svar bör de två frågevarianterna 
blandas. (Bryman, 2002) 


4.2.3 Konstruktion av våra intervjufrågor 
För att få bra svar eller rätt data vid intervjuerna strukturerade vi intervjuerna enligt Kvales 


(1996) metod där man bygger upp intervjun utifrån sina forskningsfrågor. Metoden går ut på att 
utifrån var och en av forskningsfrågorna välja intervjufrågor som tillsammans besvarar 
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forskningsfrågan. Men vi höll också i åtanke att intervjufrågorna följde Kvales råd om att skapa 
frågor som ska vara lätta att förstå, är lätta att följa upp och ger ett bra flyt i kommunikationen. 
Vidare var det viktigt för oss att de vi intervjuade var väl införstådda med vad vi frågade efter. Vi 
skickade därför e-post där vi kort förklarade vad vi sökte och vad vi skulle fråga efter (Bilaga 2). 


Nedanstående tabell visar hur vi har kommit fram till de intervjufrågor som vi ville ställa under 
våra intervjuer samt e-postundersökningar. I vänstra spalten finns våra forskningsfrågor och i 
högra spalten de intervjufrågor som respektive forskningsfråga har gett upphov till. 


Forskningsfrågor Intervjufrågor 
Hur är de automatiserade reglerna 1:a Hur förvaltar ni regler som styr er 
implementerade? verksamhet? 


3:a Har ni implementerat regler som används 
automatiskt i era system? 


3:c Ar det bara vissa typer av regler som ni har 
valt att implementera? 
Vilka är i så fall dessa? 
Hur går ni tillväga för att välja vilka 
regler ni ska implementera? 


5:b Hur avgränsar ni vilka regler som skall 
implementeras eller inte? 


Finns de inbäddade i programkod, exempelvis 
Java eller C++, eller är de separerade från 
systemet? 


3:b Dessa finns kanske i till exempel javakod 
eller SQL? 


6:a Använder ni någon mjukvara (Business 
Rule Management System) för er 
regelförvaltning? 


6:b I så fall vilket och hur länge har det varit i 
bruk? 


Hur underhålls de automatiserade reglerna? 
Ar reglerna medvetet implementerade? 


4:a Hur har ni implementerat dessa regler? 


4:b Hur underhålls dessa regler? 


4:c Hur gar ni tillväga om en regel ändras? 


Vem underhåller de automatiserade reglerna? 


4:d Vem eller vilka sköter detta och finns det 
någon som har det slutliga ansvaret? 


4:e Vilka krav och regler finns för 
implementering av reglerna i systemen? 


4:f Är regelförvaltningen en avskild 
verksamhet med någon eller några ansvariga? 
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Finns det någon form av rule repository? 5:a Har ni något Rule Repository alltså en 
lagringsenhet speciellt för regler? 

Hur beskrivs BR i organisationernas 1:b Har du hört talas om begreppet Business 

terminologi? Rules? 


2:a Vill du beskriva vad det betyder? 


2:b Vad använder ni för termer när ni 
diskuterar regelförvaltning? 


De två sista intervjufrågorna är mer öppet 7: Skulle du vilja förbättra förvaltningen av era 
ställda så att de kan ge svar på flera frågor. regler på något sätt, finns det något du saknar i 
din organisation vad gäller er regelförvaltning? 


8: Kan vi få se några exempel på hur ni har 
implementerat regler och hur detta används? 


Tabell 4.1: Konstruktion av intervjufrågor 


4.2.4 Ljudinspelning 


Eftersom den intevjuade måste godkänna att intervjun spelades in tillfrågades de givetvis först. 
Om någon av de tillfrågade hade nekat oss detta hade vi istället varit tvungna att under intervjun 
föra anteckningar. Fördelen med att spela in en intervju är att det då är enklare att koncentrera sig 
på interaktionen med den intervjuade. När man under samtalets gång skall anteckna är det risk att 
data går förlorad eller att intervjun tar onödigt lång tid. Om intervjun istället spelas in kan 
intervjun transkriberas i efterhand. Då kan sådant som inte är av intresse för datainsamlingen 
utelämnas, exempel på sådant är upprepningar eller pauser. Det bör också nämnas i 
sammanhanget att transkriberingen av intervjuer är ett val av analysmetod i sig självt (Bryman, 
2002). 


4.2.5 Transkribering 


Samtliga intervjuer spelades in, transkriberades och därefter analyserades de. Transkribering av 
intervjuerna kom att genomföras direkt efter att varje intervju hade genomförts. Detta är viktigt 
för att inte glömma bort viktig information som har med intervjusituationen att göra (Kvale, 
1996). Intervjuaren ska försöka att tyda den verkliga meningen i det som den intervjuade 
personen uttrycker. Det är därför viktigt att intervjuaren försöker tolka vad som sägs men även 
hur det sägs. Till stöd för detta arbete är en ljudinspelning oumbärlig (Yin, 2003). Det är också 
viktigt att intervjuaren är uppmärksam på tonlägen, ansiktsuttryck och kroppsspråk så att dessa 
icke hörbara uttryck hos den intervjuade under intervjun också noteras. (Creswell, 2007). 
Transkribering av intervjuerna genomförs för att vi ska kunna få en överblick av vad samtliga 
intervjupersoner har uttryckt under intervjuerna (Bryman, 2002). När transkriberingen och 
valideringen av intervjuerna var färdig började arbetet med att strukturera och analysera det 
material som våra intervjuer har skapat. 
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4.2.6 Intervjuerna 


Vi har bland annat haft för avsikt att undersöka personers inställning och upplevelser av BR- 
förvaltning, därför har våra intervjuer haft en kvalitativ inriktning. Denna hållning gav oss 
möjligheten att föra en djupare diskussion och att ställa följdfrågor under våra intervjuer 
(Alvesson och Sköldberg 1994). Det innebar även att vi var mer mottagliga för nya uppgifter 
eller data som framkom under intervjuerna. Detta induktiva sätt att undersöka ett område genom 
att söka fakta i verkligheten är lämpligt när ett område är relativt outforskat (Patel & Davidsson, 
2003; Thurén, 1991). 


Intervjuerna inleddes med att information som namn, antal arbetade år inom organisationen, 
samtycke om att spela in samtalet samt om de ville vara anonyma eller om vi kunde nämna deras 
namn i uppsatsen behandlades. Först fick intervjupersonerna en muntlig introduktion till vad vår 
uppsats behandlar och därefter genomfördes den verkliga intervjun. 


Intervju 1 genomfördes med Peter Thorsson, IT chef, och Paul Silfwerberg, systemansvarig, från 
Boverkets IT enhet, datum: 2008-04-24. Peter Thorsson har arbetat på Boverket i åtta år och Paul 
Silfwerberg i ca femton år. Efter att intervjun hade avslutats kunde Marie Appelros hjälpa till 
med att ta några skärmdumpar av Boverkets olika system. 


Intervju 2 genomfördes med Henrik Andersson, driftansvarige för IT-avdelningen på Emmaboda 
kommun, datum: 2008-04-25. Henrik har lång erfarenhet av arbetet i organisationens IT- 
avdelning och är också den som har det yttersta ansvaret under IT-chefen. Han har det största 
ansvaret vad gäller förvaltningen av kommunens system. De är fem personer som arbetar på IT- 
avdelningen och mycket av det som sker görs i samråd mellan dessa fem. 


4.3 Frågor via e-post 


Innan vi ringde för att boka våra intervjuer skapade vi e-postfrågor som kunde skickas via e-post 
i de fall de personer vi sökte inte kunde avsätta tid för en intervju (Bilaga 2). Frågorna skapades 
med de frågeställningar vi förberett till intervjuerna som grund. E-postfrågorna inleddes med en 
kort förklaring av vad vi undersökte och här förklarades även vad BR är och vilka typer av regler 
som söktes. E-postfrågorna bestod till övervägande del av öppna frågor där den svarande kan ge 
så uttömmande svar som denne tycker är lämpligt. Bryman (2002) säger dock att det kan vara 
svårt att få hög svarsfrekvens när man använder öppna frågor då dessa är mer tidskrävande än 
slutna frågor. Men med denna typ av konstruktion kan den som besvarar ge målande 
beskrivningar och det ansåg vi vara viktigast. Genom avtal per telefon lovade de vi tagit kontakt 
med att läsa frågorna och om denne inte själv kunde svara på dem skulle han eller hon 
vidarebefordra dem till rätt person. Detta alternativa insamlingssätt av data gjorde det möjligt att 
få svar från fler respondenter än om personliga intervjuer varit det enda alternativet. Via telefon 
ställdes också frågan om det fanns möjlighet att ställa uppföljande frågor via e-post eller telefon 
och detta godkändes genomgående. Detta ökar kvalitén då den intervjuade har samma möjlighet 
som vid en personlig intervju att fritt uttrycka vad han/hon tycker och känner (Kvale, 1996). Det 
ger även intervjuaren möjlighet att följa upp och förtydliga frågor (Kvale, 1996) där svaren inte 
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känns tillräckliga eller där det finns risk för feltolkningar. Nackdelen med denna öppna 
konstruktion är att kvalitativ data tar längre tid att bearbeta (Kvale, 1996). 


E-postfrågor 1 besvarades av Tommy Hurtig Systemtekniker på Flygts IT-avdelning Sundbyberg. 
Svaret mottogs 2008-04-28. E-postfrågorna skickades först till Ingemar Carlsson på kontoret i 
Lindås som sedan vidarebefordrade den till Eva Karlsson på Flygts IT-avdelning i Lindås. Eva 
Karlsson vidarebefordrade frågorna till Tommy Hurtig som hon tyckte bäst kunde svara på våra 
frågor. 


E-postfrågor 2 besvarades av Mats Löfgren, IT-chef på Karlskrona kommun. Svaret mottogs 
2008-04-22. 


4.4 Bearbetning av data. 


Genom att transkribera och analysera de data vi samlat in kunde vi genomföra våra tolkningar. Vi 
kategoriserade de svar vi fick och sammanställde dessa data i tabeller och listor. 


4.4.1 Kodning av intervjuer och E-postfrågor 


Genom att, som Miles och Huberman (1984) föreslår, visualisera de intervjusvar och svaren på e- 
postfrågorna vi fått kunde vi få en överblickbar faktabas. Detta skedde genom att transkribera 
intervjuerna och sedan upprätta likartade dokument för svaren på e-postfrågorna. Genom att ge 
fenomen eller yttranden olika koder beroende på vad de behandlar kan man lättare hitta uttryck 
som behandlar samma område (Miles & Huberman, 1984). Vi gjorde upp en tabell för vilka 
koder som vi skulle använda och valde att välja en kod för varje forskningsfråga som vi ställt (se 
tabell 4 nedan) men vi lade även till en kod (kod 2) som indikerade sådant vi tyckte var intressant 
men hamnade utanför forskningsfrågorna. Vi gjorde sedan en tabell med två kolumner där den 
ena innehöll de svar vi erhållit på våra frågor medan den andra användes för att skriva in våra 
koder. Detta gör det enkelt att, som Miles och Huberman (1984) beskriver, hitta mönster i 
materialet. Vi kunde genom detta arbete sammanställa fakta på ett sätt som gjorde det enklare att 
tyda men detta stödde även arbetet att få materialet godkänt av de vi fått svar från. Med detta 
menar vi att vi kunde skicka de uppgifter och fakta vi sammanställt genom detta arbete till de 
svarande så de kunde validera att vi inte misstolkat något. 


Kod | Forskningsfraga 

la a. Hur ar de automatiserade reglerna implementerade? 

1b b. Hur underhalls de automatiserade reglerna? 

1c c. Vem underhåller de automatiserade reglerna? 

1d d. Finns det någon form av rule repository? 

le e. Ar reglerna medvetet implementerade? 

1f f. Finns de inbäddade i programkod, exempelvis Java eller C++, eller ar de separerade 
fran systemet? 

1g g. Hur beskrivs BR i organisationernas terminologi? 

2 Övriga intressanta kommentarer. 
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Tabell 4.2: Kodning av intervju- och e-post-frågor 


Här följer några exempel på hur transkriberingar och svar på e-postfrågorna kodades. 

Ja de blir bra. Hur förvaltar ni regler i organisationen? 

la | Hur vi hanterar regler som styr vår verksamhet? (han läser på lappen) Det vi har 
automatiserat idag är på skolsidan när det gäller användarna. 

1b | Så att de användare som kommer till som är, som kommer till och som bildning 
(bildningskontoret) skriver in i sitt system skapas och tas bort med automatik i 
användarregistret eller om man ska säga AD:t då, så det styrs av regler. 

2 | Nar det gäller administrativa nätet och har vi regler beroende på vilka grupper de tillhör, 
men vi har inget med automatik där. Så jag får sitta och skriva in vilka grupper de tillhör 


och vilka rättigheter . 


la | Hur lägger ni regler eller kodar har ni något kodat i Java eller någon mjukvara? 

1d | När det gäller skolan så är det ett litet program som ligger ut hos ett externt företag som 
1e | gjort det. Som hämtar från en databas och lägger in det i AD:t i det här fallet. 

1c | Kan du själv ändra några regler i det programmet? 

1b | Nej då måste jag ta kontakt med företaget, det har fungerat så bra med att vi har sagt vilka 
regler som ska gälla och så har de fixat det. Så de sköter all support och uppdatering med 
mera där. I det administrativa får man gå in manuellt och klicka klicka klicka på varje 
användare och vad de ska ha för tilldelning. 


1c | 4:d Vem eller vilka sköter detta och finns det någon som har det slutliga ansvaret? 
Slutgiltiga ansvaret har alltid processansvarig (eller systemägaren). Förvaltaren är den som 


genomför förändringarna i systemen. 


2 7: Skulle du vilja förbättra hanteringen av era regler på något sätt, finns det något du 

saknar i din organisation vad gäller regelhantering? 

Det saknas alltid regler som är klara och väl definierade samt utsedda av en stark styrning. 
Tabell 4.3: Kodning av intervju- och e-post-svar 


4.4.2 Analys av data från intervjuer 


”Member checking” eller ”member validation” är en term som används inom kvalitativ forskning 
och i samband med att forskare arbetar med andra personers ord eller åsikter. Termen är aktuell 
under arbete med intervjuer och tolkning av dessa. En av ingredienserna i ”member checking” är 
att få den intervjuades validering av att tolkningen av intervjun är riktig. När våra intervjuer var 
transkriberade och vi hade gjort våra tolkningar av materialet lät vi intervjupersonerna studera 
och godkänna materialet. Genom att få intervjupersonernas godkännande, validering, försökte vi 
säkerställa en god kvalité på den kunskap vi utvunnit (Seale, 1999; Creswell, 2007). 


Vi valde att först samla in material via intervjuerna för att sedan transkribera dessa. Samtidigt 
som transkriberingen skedde analyserades också materialet. Vi har även utnyttjat möjligheten att 
efter analysen ställa frågor via e-post till de intervjuade för att klarlägga tolkningar eller för att få 
bekräftat att vi tolkat de intervjuade rätt. Det dök även upp nya frågor under analysens gång vilka 
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vi också kunde söka svar på hos de vi intervjuat. På detta sätt får vår analys ett inslag av iteration 
som vi tycker stärker den. (Bryman, 2002) 


4.4.3 Analys av data från e-postundersökningar 


För att få kompatibilitet mellan svaren vi fått från intervjuerna och e-postfrågorna valde vi att 
nedteckna svaren på e-postfrågorna på samma vis som vi gjort med intervjuerna. Vi kunde sedan 
koda och analysera svaren på e-postfrågorna och intervjuer gemensamt och på samma sätt. Om vi 
fann oklarheter i materialet kunde vi, liksom med intervjuerna, få detta förtydligat genom att 
ringa eller skicka e-post till de svarande. 


4.5 Etik 


Skillnaderna är stora mellan vad som anses rimligt eller etiskt i olika religioner, kulturer och 
stater. Etiska frågor har inte haft så stor effekt på vår forskning då vi inte kommit in på några 
särskilt känsliga områden. Däremot har känsliga områdena som vi berört genom vår forskning 
handlat om våra intervjupersoners, de som besvarat e-postfrågorna och deras organisationers 
samtycke och integritet. Vi anser att den information vi gett de medverkande och deras möjlighet 
att studera och ge synpunkter på våra slutsatser gett tillräcklig täckning för att vår forskning inte 
ska anses oetisk. (Israel & Hay, 2006) 


Israel och Hay (2006) skriver även att det är viktigt att arbeta för att minimera eventuella risker 
och skador som intervjudeltagare kan drabbas av. Utan att lätta på våra kvalitetskrav har vi 
arbetat för att detta skulle genomsyra vårt arbete. Vi ville att alla personer som deltog i våra 
undersökningar skulle känna sig tillfreds i situationen och att alla, i högsta grad, skulle svara så 
sanningsenligt som möjligt på alla frågor. För att alla intervjupersoner som deltog skulle känna 
sig trygga i situationen var det viktigt att vi kunde erbjuda dem anonymitet. Därmed är det viktigt 
att de som besvarar frågor känner sig säkra på att inte någon annan person än forskarna eller 
intervjuarna ska kunna ta reda på vad de har svarat om de så önskar. (Israel & Hay, 2006) 


När vi konstruerade våra intervjufrågor hade vi även i tanken att det inte skulle vara möjligt att 
kunna avslöja den svarandes identitet genom svaren. Vi har inget speciellt intresse av att avslöja 
personliga fakta om de svarande och det tillför inte våra resultat något speciellt. Det enda som gör 
att vi presenterar de svarande är för att öka validiteten då den som läser ges möjlighet att 
kontrollera vår fakta. Det hade varit svårt att få någon trovärdighet i våra fakta om övervägande 
delen av de svarande hade velat vara anonyma. (Collste, 1996) 


Vetenskapsrådet (2008) ger stöd för vilka etiska aspekter som kan vara aktuella vid forskning. De 
tre råd som vi främst tog under övervägande i våra e-postfrågor och intervjuer var 
informationskravet, samtyckeskravet och konfidentialitetskravet. Informationskravet innebar att 
vi informerade om vilket syfte vi hade med våra frågor och även att vi kort beskrev BR för de 
svarande. Detta gjordes vid första telefonkontakten men upprepades även i e-post och vid 
intervjutillfället. Vi säkerställde de svarandes samtycke, samtyckeskravet, genom att förklara att 
medverkan var helt frivillig och att de när som helst kunde dra sig ur undersökningen. Vi 


47 


Bohman, C. & Nordgren, J. (2008) 


lämnade även telefonnummer och e-postadress där de svarande kunde nå oss om de ville ändra 
eller tillägga något. Vid våra intervjuer klargjorde vi för de intervjuade att vi om de så önskade 
inte behövde nämna deras namn eller organisation. Vi påtalade även att det skulle vara positivt 
för vårt arbete om vi fick omnämna dessa uppgifter då det ökar validiteten i vårt arbete. 


4.6 Validitet och reliabilitet 


Seale (1999) skriver att begreppen reliabilitet och validitet används för att granska kvaliteten av 
en undersökning. Reliabilitet innebär huruvida likvärdiga undersökningar kommer att leda till 
likvärdiga resultat. Denna uppsats innehåller en grundlig beskrivning av undersökningsdesignen 
samt av de undersökningsmetoder som har använts. Detta är viktigt för att andra ska ha möjlighet 
att genomföra en liknande undersökning. Reliabilitet handlar också om hur trovärdiga våra 
resultat och källor är. I den mån det har varit möjligt har vi använt oss av akademiskt eller 
vetenskapligt beprövade källor såsom artiklar och annan litteratur från välrenommerade forskare. 
Sådan litteratur har redan genomgått en vetenskaplig prövning för att bli publicerad vilket kan 
vara en fingervisning om trovärdigheten. Därutöver har vi under arbetets gång fört en diskussion 
om sekundärdatans trovärdighet. Vi har uteslutande använt oss av källor som vi båda har 
kontrollerat. 


Validitet innebär huruvida de data som har samlats in genom undersökningar med mera stämmer 
överens med verkligheten (Bryman, 2002). Under intervjuerna har vi jobbat för att inte ställa 
ledande frågor utan låta intervjupersonerna utveckla sina egna resonemang. Det var även viktigt 
att vi som intervjuare var öppna för nya oväntade insikter i problemområdet som kunde komma 
upp under intervjuerna. 


För att avgöra om de data som samlats in stämmer överens med verkligheten används begreppen 
tillförlitlighet och överförbarhet (Seale, 1999). Bryman (2002) skriver att en fyllig redogörelse 
eller en tät beskrivning ska förse andra personer med tillräcklig information för att de ska kunna 
bedöma hur pass överförbara resultaten är till en annan miljö. För att underlätta överförbarhet och 
höja tillförlitligheten innehåller denna uppsats en beskrivning av metodförfarandet och urvalet. 
Under arbetet med att framställa uppsatsen har handledare och andra uppsatsstudenter fått tillfälle 
att kritisera den. Detta har medfört att undersökningen har blivit granskad av utomstående 
personer med kunskap i undersökningsprocessen vilket enligt Seale (1999) kan stärka 
tillförlitligheten. 
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5. Kort om våra fallorganisationer 


I detta kapitel presenteras en kort beskrivning av våra fallorganisationer. 


5.1 Boverket 


Boverket är en nationell myndighet som ansvarar för frågor om samhällsplanering, stads- och 
bebyggelseutveckling, byggande och förvaltning, administration av statliga bostadsstöd av 
bidrag, stöd till finansiering av bostäder och andra bostadsfrågor. Boverket arbetar exempelvis 
med att ta fram föreskrifter för nya byggnader så att dessa ska vara hälsosamma och säkra. 
Myndigheten analyserar också bostadsmarknaden vad gäller segregation, hur människor bor samt 
tillgången på bostäder runt om i Sverige. Vid Boverket arbetar ca 200 personer som bland andra 
är arkitekter, civilingenjörer, jurister, planerare, beteendevetare och informatörer. Boverket 
bildades 1988 när Planverket och Bostadsstyrelsen slogs ihop och har sedan 1989 funnits i 
Karlskrona. (Boverkets hemsida, 2008) 


Boverket består av två stycken divisioner samt dess stödenheter. Ansvaret för boverkets olika 
uppdrag fördelas på divisionerna samhällsbyggnadsdivisionen och husbyggnadsdivisionen. 
Därutöver finns fem stycken stödenheter. (Boverkets hemsida, 2008) Nedan syns en bild av 
boverkets organisation (Boverkets organisation, 2008). 


Stödenheter Husbyggnadsdivisionen Samhallsbyggnadsdivisionen 
(Overdirektér) Divisionschef Divisionschet 
Verksledningens kansli Bidragsenheten Analysenheten 
Ekonomienheten Bygg- och férvaltningsenheten Planenheten 
nformationsenheten Byagregelenheten Stads- och regionenheten 
T-enheten 


Personalenheten 
och Servicecenter 


Figur 5.1: Boverkets organisation. 


Mycket av Boverkets verksamhet grundar sig pa att staten beslutar om olika lagar och 
förordningar som sedan måste verkställas. Dessa lagar och förordningar innehåller flera olika 
bestämmelser, vilka kan vara mer eller mindre vaga, som sedan boverket ska förvalta vilket de 
väljer att göra på olika sätt. Beroende på vagheten i vissa bestämmelser har Boverket också en 
föreskriftsrätt vilket medger att Boverket även kan förtydliga de bestämmelser de fått från staten 
och som Boverket ska förvalta. Dessa föreskrifter, som Boverket själva gör, och bestämmelser är 
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det material som ligger till grund för de BR som boverket sedan implementerar i sina system, 
vilket allt sammantaget är en ansenlig mängd regler. Samhällsbyggnadsdivisionen 

och husbyggnadsdivisionen är i sin tur uppdelade i olika enheter som var och en ansvarar för en 
begränsad del av de uppdrag som boverket har. De BR som hör till bidrag förvaltas av 
bidragsenheten och de BR som rör byggande förvaltas av byggregelenheten med mera. 
Stödenheterna finns till för att hjälpa Boverkets olika enheter i den dagliga verksamheten. 


5.2 Emmaboda & Karlskrona Kommun 


Emmaboda kommun består av drygt 9 500 invånare och Karlskrona av drygt 60 000. 
Kommunerna är uppbyggda på ett likartat sätt och består av olika förvaltningar samt 
koncernbolag som bedrivs som helt eller delvis fristående företag. I Karlskronas organisation 
ingår 5 700 anställda samt 6 900 elever vid kommunens grundskolor i Emmaboda är motsvarande 
siffror 900 anställda och 3 500 elever. Nästintill alla dessa är på något vis användare av 
kommunernas IS och IT. Det är dessa anställda och elever som berörs av den kommunala IT- 
strategin och alltså påverkas av det som sker inom IT-avdelningen. I figuren nedan illustreras i 
enkla drag IT-avdelningens position och uppgift i organisationen. 


Kommunens- 2 
ledning Grundskolan 
Mal och visioner Barn och Ungdoms 
Budget förvaltningen S 
é eo y 
IT i Drift, support av system samt Ovriga S 
chef tilldelning av nätverksresuser förvaltningar t 
Besky och budget e 
Koncernbolag e 
IT- m 
avdelning ä 
8 
a 
ipphandlas r 
e 


Koncernbolag 
helt fristående 


Figur 5.2: IT avdelningens roll i kommunerna 


Genom våra intervjuer framkom att kommunerna är regelstyrda organisationer som i första led 
styrs av politiska beslut. IT-chefen har förvaltning och budgetansvar och IT-avdelningen lyder 
direkt under denne. IT-avdelningen har det största ansvaret vad gäller förvaltning och drift av 
kommunens IT och IS. Förutom nätverket äger i regel IT-avdelningen på en kommun inte några 
system utan ägare är de olika förvaltningarna inom organisationen. Som syns i figuren ovan har 
IT-avdelningen en stödjande roll mot de övriga förvaltningarna och koncernbolagen. 
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5.3 ITT Flygt 


Flygt, ITT, startades 1901 i Lindås som ett litet företag men har vuxit till en världskoncern med 
mer än 4 000 anställda världen över. Dränkbara pumpar är företagets viktigaste produkt och 
mycket av tillverkningen finns vid fabriken i Lindås. Där arbetar över 1 000 personer fördelade 
på fabriksgolv och kontor och företaget är Emmaboda kommuns största arbetsgivare. Flygts har 
även tillverkning i Tyskland, Kina, Italien, Argentina och Holland och kontor runt om i världen. 
Huvudkontoret ligger numera i Sundbyberg utanför Stockholm, där det finns över 600 anställda. 
IT-avdelningen har cirka 55 personer, dessa finns både i Lindås och i Sundbyberg, och de 
ansvarar tillsammans för 400 servrar och 4 000 persondatorer. Det blir en del resande för de 
anställda på avdelningen, främst inom Sverige men även till kontor och fabriker på andra platser i 
världen. Flygt ingår sedan 1960-talet i den världsomspännande koncernen ITT. Flygt byter under 
ar 2008 namn till ”ITT Water & Wastewater” där Flygt kommer att finnas kvar som produktnamn 
på företagets pumpar. 
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6. Hur förvaltas BR i IS & IT i våra fallorganisationers 
dagliga verksamhet 


Detta kapitel redovisar hur BR förvaltas av våra fallorganisationer. Detta redovisas utifrån 
forskningsfrågorna, vilka är representerade som rubriker i kapitlet. 


6.1 Hur är de automatiserade reglerna implementerade? (1a) 


Från de två svaren på e-postfrågorna (Flygt, Karlskrona Kommun) och en av intervjuerna 
(Emmaboda kommun) kan man utläsa att dessa organisationer är lite osäkra på hur reglerna 
egentligen är implementerade i systemen. Svaren visar samtidigt att dessa tre främst tänker på 
regler i egenskapen av sådana som begränsar användarnas rättigheter inom de olika systemen. De 
två kommunerna talar just om kontroll av användarnas rättigheter och åtkomst av information 
med mera och att dessa regler sköts automatiskt via systemen. Flygt lägger även till aspekten av 
regler som styr processer. Flygt säger sig även ha regler implementerade i en rad programspråk så 
som Cobol, VB, .NET och så vidare. I en av kommunerna säger de sig ha lagt ut 
regelförvaltningen och implementeringen av vissa regler på en underleverantör. Detta gäller de 
regler som styr användarrättigheter på skolorna runtom i kommunen, både för elever och 
personal. De tar själva fram regelspecifikationer men efter detta tar underleverantören över. Det 
framkommer att de flesta regler i de kommunala verksamheterna hanteras manuellt och att detta 
även sker lokalt på de olika förvaltningarna och avdelningar inom dessa organisationer. Det är 
alltså övervägande i programkod vi finner de implementerade reglerna i dessa tre organisationer. 


På Boverket har man flera olika system som används för att stödja olika delar av verksamheten. 
De automatiserade reglerna finns därmed implementerade i flera olika system. Många av reglerna 
är implementerade i olika programspråk och de är också på Boverket lite osäkra på hur vissa 
regler är implementerade. Men de har också några system som innehåller väl medvetna 
implementeringar av regler. Tre av dessa presenterades närmare under vår intervju och beskrivs 
här nedan. De olika verksamhetsunderstödjande systemen har man inom Boverket valt att 
namnge efter fåglar. 


Det system som står ut mest från de övriga är ett system som Boverket kallar för Skatan. Skatan, 
som Paul Silfwerberg är systemansvarig för, är ett bidragssystem som hanterar bestämmelserna 
för alla de bidrag som Boverket administrerar i boendefrågor, vilket resulterar i många 
implementerade regler. Boverket kallar Skatan för ett reglerverk och där implementeras alla 
bestämmelserna i en databas som består av ett åttiotal olika tabeller. Enligt uppskattning 
innehåller Skatan en regelmängd på mellan 175.000 till 200.000 regler av varierande dignitet. 
Skatan är i grunden uppbygg i Oracle men eftersom Boverket för två år sedan började gå över 
mer och mer till Microsofts produkter pågår arbetet med att föra över databasen till Microsofts 
verktyg. Skatan används för att hantera många av de externa BR som gäller för de andra 
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systemen. Figuren nedan visar hur en tabell i Skatan kan se ut. Tabellen visar ett antal bidrag som 


är uppdelade på hustyp och från vilket konto pengarna ska dras med mera. 
ER BOFR0014 = Stödformskonto (STOKTO) 


Stödformskonto 298 rader 


Stöd S Stöd ” Hus * Upp. ~ Ska,” Prod, * Agar” a SER Kostnadsställ a 
ändamål typ typ a a or verksamhet Prestation = Finansiar 


542303 
542303 
[542303 
542303 
542303 
542303 
542303 
542303 
540701 
[540701 
540701 
540701 
540701 
540702 
540702 
540702 
540702 
540702 
540702 
540702 


540702 


2|2|2|2|2|2|2|2|9|2|2|2|2|ə|ə|2|2|2|2|2 


=|IlIlIlI]I]o]o|»]|krI).kI|»|&- 


Figur 6.1: En tabell i Skatan 


Figur nedan visar en lista med variabler som med olika kombinationer bygger upp de regler som 
Boverket har för alla bidrag. 
ES] BOFR0027 Wariabel(VARTYP) 


variabel 1314 rader 


| á Pres. ord * Klartext y a) 
0 HIALPYARIABEL AATERAMOSRBX, UTBBERAK 

| AASAKTATERBEL a 0 SAKNAS 

| AATERAMORBX 0 HJÄLPVARIABEL AATERAMOSRBX, UTBBERÄK 
ACKKR = | 0 BERÄKNAT BIDRAG I ACK 
AKTATERBEL | 0 HJÄLPVARIABEL 

| ALDREBOST 0 BOSTÄDER AVSEDDA FÖR ÄLDRE 
AMEDGIVANDE J 0|" 1 "ärendet har fått medgivande för påbörjande 

| AMOL 0 AMORTERINGSBELOPP, (50 ÅR) 

| AMO2 | oj AMORTERINGSBELOPP, (40 ÅR) 

| AMO3 | 0 AMORTERINGSBELOPP, (30 ÅR) 

| AMOBEL | 0) AMORTERINGSBELOPP 
AMOBELFOR | 0| AMORTERINGSBELOPP FORKOPSFORVARY 

| AMÖRTSUM ol Summa amorteringar tom i innevar. Beräkn. Period 
ANDEL | -0 Bidragsandel, % o 

| ANDELNY 0 Bidragsandel, % för Igh <= 70 m2 BOA (även stimul) 
ANGEUNGBOST | 0 "1" anges för ungdomsbostäder, "2" för studentbost 

| ANNANLYFT | 0| Antal annan lyftanordning 

| ANSOKANLAN ol Även ansökan om bostadslån har inlämnats i ärendet 
ANTDAGBER | O/UTBETANTAL BERÄKNINGSDAGAR  ž 

| ARBAKTSBSAND 0 Hjälpvariabel för | beräkning av aktfullsbsand 

| ARBDEL 7 5 0 Hjälpformel, delkonvertering v| 


Spara och stäng 


Figur 6.2: Regler i Skatan 
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Det system som används för att administrera och styra handläggning av ansökningar om bidrag 
för bostäder och byggnader benämner Boverket för Bofink. Bofink är ett administrativt system 
medan Skatan är ett register för alla regler. 


Skatan och Bofink innehåller även interna regler. Boverket har övergripande bestämmelser som 
gäller för hur de statliga bidragen ska hanteras. Exempelvis har Boverket uppdraget att följa upp 
effekterna av dessa bidrag. Detta görs genom en utvärdering för att avgöra om man har uppfyllt 
det mål som har satts upp av regeringen för respektive bidrag. I och med att Boverket har en 
föreskriftsrätt så kan de föreskriva regler för hur ärenden som ansökningar om bidrag och 
uppföljning av effekterna av bidragen ska hanteras inom Boverket. Boverket föreskriver regler 
som begränsar användarna av systemen så att de måste ange olika uppgifter och värden på rätt 
sätt. Dessa regler finns implementerade i programkoden för Bofink och Skatan och genomför 
automatiska valideringar på de uppgifter som skrivs in i systemet när en individ söker ett bidrag. 
Dessa automatiska BR kontrollerar så att användaren av systemet inte ska kunna lägga in 
felaktiga eller orimliga värden som sen ska användas för beräkning av bidragen. Dessa BR är 
Boverkets egna interna regler. 


Eftersom också länsstyrelserna jobbar i Bofink finns det ett behörighetssystem som hanterar vem 
som har tillgång till att göra vad. För att en handläggare ska kunna få olika behörigheter i Bofink 
krävs det att personen gör en ansökan till Boverket. Boverket genomför då en beslutsprocess som 
antigen kan bevilja en ansökan om behörighet eller avslå den. Dessa regler för behörigheter har 
Boverket implementerade i ett system som de benämner Höken. Höken hanterar alla de 
behörigheterna som är uppbyggda på olika roller vilka begränsar så att användare får göra olika 
mycket i systemen och får tillgång till olika mycket av uppgifterna/informationen som finns 
samlade i Boverkets system. 


Därutöver genomför Boverket energideklarationer. Det pågår ett arbete med att energideklarera 
många av Sveriges ungefär 3,4 miljoner byggnader. I detta arbete ska Boverket registrera 
besiktningarna samt innehållet i dessa besiktningar. Boverket har därför byggt upp ett register i 
vilket detta ska deklareras. Systemet innehåller många automatiserade regler och många av dem 
är beräkningsregler. Systemet ska utifrån den information som har skrivits in i registret producera 
något som Boverket kallar lappen i trappan. Denna lappen i trappan talar om hur pass 
energieffektiv en byggnad är genom att placera den i förhållande till ett normvärde som är baserat 
på likvärdiga byggnader. Även detta system innehåller behörighetsregler. Olika certifierade organ 
med besiktningsmän måste begära att få behörigheter i systemet. Dessa begäranden sker till en 
högre nivå än Boverket men det är de som har ansvaret för registret och som implementerar 
reglerna för behörigheterna. 


Utöver dessa system har Boverket också ett lönesystem och ett beställningssystem som innehåller 
många implementerade regler i programkod. 


54 


Användning av och kunskap om Business Rules i svenska organisationer. 


6.2 Hur underhålls de automatiserade reglerna? (1b) 


På Flygt och hos Karlskrona kommun samt till viss del även hos Emmaboda kommun finns det 
systemförvaltare och systemtekniker som tillsammans sköter underhållet av reglerna. Detta 
innebär i princip att de tillsammans diskuterar hur och vilka regler som behöver uppdateras. Man 
tar gemensamt fram specifikationer och ramar på hur de uppdaterade reglerna skall verka i 
systemen. Det är dock systemteknikerns roll att se till att arbetet blir utfört. Det är vanligt inom 
organisationerna att detta underhållsarbete läggs ut på underleverantörer. Dessa underleverantörer 
är oftast desamma som levererar och eller står för driften av system. I Emmaboda säger de sig 
även ha underhåll av vissa regler utlagd på de olika förvaltningarna men att detta främst gäller 
användarnas olika rättigheter i systemen. Inom Flygt säger de att det beror på reglernas dignitet 
av vem och hur de ändras. Om dessa styr invecklade processer skall förutom systemförvaltare 
och systemtekniker även processansvarig medverka. Gemensamt för de tre organisationerna är att 
underhållet oftast sker lokalt, det utförs manuellt i olika system och på olika avdelningar. Det 
finns inte någon manual eller annan dokumentering hur regler skall uppdateras eller hur man 
finner reglerna. I alla dessa tre organisationer måste man söka igenom kod eller databaser för att 
finna och uppdatera eller ta bort regler. 


Hur reglerna på Boverket underhålls avgörs liksom på Flygt av vilken regel det är som behöver 
ändras. På Boverket finns det ingen generell process för reglerhantering utan många av de regler 
som hanteras i systemen modelleras och programmeras när det enskilda systemet byggs upp. 
Boverket utvecklar inte alla sina system själva utan många beställs. Om en systemförändring ska 
ske i ett sådant system måste man kontakta en konsult, förändringen görs sedan i nära samarbete 
med den systemansvarige på Boverket. 


I Boverkets regelverk för bidrag, Skatan, uppdaterar anställda själva de bestämmelser som ligger 
implementerade i tabellerna. När det kommer ett nytt stöd till Boverket inleds arbetet med att 
uppdatera tabellerna och informationen i dem. Att en regel måste ändras kan bero på att en 
medarbetare vid Boverket gör en uppföljning av ett bidrag (statlig stimulans) och upptäcker att 
bidraget inte har uppfyllt det avsedda målet, stimulansen har inte fått förväntad effekt. Detta 
meddelar Boverket till regeringen som därefter ändrar den specifika förordningen och dess 
bestämmelser. Under arbetets gång för Boverket en dialog, på pappersnivå, med det departement 
som är ansvarigt för den specifika förordningen, om hur ändringen bäst ska genomföras. Parallellt 
med detta analyserar också Boverket sina system för att klargöra hur systemet kan hantera en 
specifik regeländring. 


Boverket genomför viss systemutveckling själva. Detta görs med modellering, till exempel UML, 
som hjälpmedel. För att verkställa en regeländring i Skatan ändras antingen reglerna i tabellerna i 
databasen eller kompletteras de med några nya regler. Skatan innehåller funktioner för att 
underlätta uppdatering av regler. Det handlar då främst om sökverktyg för att kunna hitta den 
regel som ska ändras. Sökverktygen är implementerade som ett antal rullgardiner i systemets 
grafiska användarfönster. Många av reglerna som är implementerade i Skatan är beräkningar och 
olika formler skrivna i programkod. För att underlätta uppdateringar eller omskrivningar av 
sådana regler så innehåller Skatan något som benämns formelhjälpredor. Formelhjälpredorna 
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visar utdrag ur själva programkoden som den specifika regeln är realiserad med. De hjälper 
användarna att skriva formlerna i programkoden på rätt sätt, att de får dit de dubbla parenteserna i 
början och att det verkligen finns samma antal i slutet och så vidare. Formlerna i programkoden 
beskrivs som relativt komplicerade och man menar att det inte vore det allra enklaste att 
uppdatera dem på fri hand direkt i koden. 


Nedan syns en figur som visar hur uppdatering av reglerna genomförs. Användaren har i figuren 
nedan klickat på ett bidrag som kallas DIRELBIDRAG i systemet. Systemet ger en beskrivning 
av vad bidraget är samt ett utdrag ur programkoden som regeln är implementerad med. 
Användaren genomför regelförändringen i kodutdraget i detta fönster. 


Hl BOFROOO9 Formel (FORMEL) 


Formelkod 


DIRELBIDRAG Formeltest 
Formelbeskrivning i 


Krediteringsstöd för konvertering från direktverkande elvärme DIREL 2005 12 28 KES, 
ANH 


Formel ” 


DIRELUNDERLAG^O?0:AYRUNDA(((DIRELANDEL/ 1 00*(DIRELUNDERLAG) >(30000"ANTA 
LLGHARB)?(30000*4NTALLGHARB+SOLSCHABL ON-KONVERAYDRAG):DIRELANDEL/100 
*(DIRELUNDERL AG)+SOLSCHABLON-KONYERAVDRAG) <0)?70:DIRELANDEL/100*(DIREL 
UNDERLAG)>(30000*4NTALLGHARB)?(30000*4NTALLGHARB+ SOLSCHABLON-KONYER 
AVDRAG):DIREL ANDEL/100*(DIRELUNDERLAG)+-SOLSCHABLON-KONVERAVDR AG,0) 


Spara och stang 


Figur 6.3: Skatan + förklaring hur regelkoden uppdateras. 


Vissa av reglerna är även implementerade i fler än en tabell. För att uppdatera en sådan regel 
behöver flera tabeller ändras och detta måste göras i en speciell ordning. För att uppdatera en 
regel som finns implementerad i tre olika tabeller måste exempelvis användaren börja med att 
förändra tabell ett innan användaren kan göra förändringar i tabell två. Detta beror på att de regler 
som finns implementerade i tabeller anropar andra regler i andra tabeller och så vidare. Det vill 
säga programkoden som finns under dessa regeltabeller är implementerad på olika platser i 
systemet. I Skatan finns det implementerade manualer som ska hjälpa användare med detta. 
Manualerna hjälper användarna att bygga upp reglerna i tabellerna på rätt sätt. De beskriver rätt 
förfarande för hur en regel ska implementeras om en användare börjar göra fel. 


Nedanstående figur visar en hjälpfunktion för hur regler ska implementeras. Hjälpfunktionen 
talar om för användaren hur reglerna ska byggas upp. 
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EE BOFR0011 Uppmätningsdata (UPP TAB) 


Uppmätningsdata 988 rader 


Pres. ord. " Klartext 


0| Ange "1" för ungdomsbost, "2" för studentb... Ange "1" för ungdomsbost, "2" för studentbost (0) 
IANTALFAST 0 Ange antal fastigheter vid Fler än 1 Ange antal fastigheter vid Fler än 1 
IATERBELACK 0 Aterkravsbelopp investeringsbidrag, ACK. Återkravsbelopp investeringsbidrag, ACK. 
IATERBELBFI 0 Återkravsbelopp inomhusklimat Aterkravsbelopp inomhusklimat 
IATERBELESS 0 Aterkravsbelopp extra statligt stöd Aterkravsbelopp extra statligt stöd 
IATERBELFIM 0 Återkravsbelopp inomhusmiljön Återkravsbelopp inomhusmiljön 
IATERBELOMBA 0 Aterkravsbelopp ombyggnadsbidrag aldrebo... Aterkravsbelopp ombyggnadsbidrag äldreboende 
IATERBELRADB 0 Aterkravsbelopp radonbidrag Aterkravsbelopp radonbidrag 
IATERBELSIN 0 Aterkraysbelopp investeringsbidrag, SIN Aterkravsbelopp investeringsbidrag, SIN 
IBELOPP 0 Sökt stöd, kr Sökt stöd, kr 
IBEVEFBBIDRAG 0 Ange med"1"om extra statligt stöd beviljats .., Ange med"1"om extra statligt stöd beviljats (ess). 
IBIDRAGBELOPP 0 Sökt bidrag, kr (0) Sökt bidrag, kr (0) 
IBLANDAT 0 Bade normal- o studbost i proj, 1= ja, 2=ne... Både normal- o studbost i proj, 1= ja, 2=nej, (0) 
IBYGGAR 0 Ange nybyggnadsår (0) Ange nybyggnadsår (0) 
IEKOUNDERLAG 0 Godkänd kostn. ekologiska åta vid bostadby.., Godkänd kostn. ekologiska åtg vid bostadbyggande 


[ Spara | [Spara och stäng ] f Avbryt 


Figur 6.4: Hjälpfunktion i Skatan 


6.3 Vem underhåller de automatiserade reglerna? (1c) 


Vem som underhåller de automatiserade reglerna beror på vilket system som reglerna behöver 
ändras i. Boverket har avgränsat systemet till att hantera olika saker och har utsedda ansvariga 
och medarbetare för varje system. På Emmaboda kommun säger de sig ha god kontroll över sina 
regler även om arbetet med underhåll till stor del sköts manuellt. Med att underhålla manuellt 
menar de att de till exempel uppdaterar tilldelning av utrymme på servern för varje användare 
snarare än att de ändrar detta automatiskt för en typ av användare. Att detta fungerar bra 
tillskriver intervjupersonen främst det faktum att kommunen har få användare i sina system och 
arbetet därför inte är så tidskrävande. De säger även att mycket av regeluppdateringar och 
underhåll sköts hos de olika förvaltningarna med stöd av IT-avdelningen och att det då faller sig 
naturligt att någon på förvaltningen reglerar reglerna. På Emmaboda kommun säger man att man 
ser fram emot när ett nytt administrationssystem ska tas i bruk. Detta system är utvecklat och ska 
användas i samverkan med en annan kommun. Systemet är tänkt att underlätta regelstyrningen 
och hanteringen av användare. 


Boverket utvecklar inte hela sina system själva utan de beställer delar av dem, men man arbetar 
för att kunna bestämma mer över systemen själva. För att inte Boverket ska vara alltför beroende 
av spetskompetens hos olika konsulter har de gått från att ha ett utkontrakterat stordatorsystem 
till att själva handha sina system. De har också, i början av det här året, bildat en IT-enhet för att 
själva kunna göra en del av det arbetet som de tidigare har utkontrakterats till konsulter. Därmed 
ska de successivt börja ta över arbetsuppgifter som tidigare har utförts av konsulter. Att Boverket 
ska kunna ha egen systemutveckling beskrivs som viktigt för att de då inte är lika beroende av 
utomstående konsulter utan har möjlighet att styra viss utveckling av systemen själva. 


De personer som underhåller regler som finns implementerade i systemen beror alltså på om 
Boverket själva har ansvaret för systemet eller om det är kontrakterade konsulter som genomför 
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förändringar i systemet. Underhåll av regler i system som systemleverantörer levererar till 
Boverket, genomförs av leverantören i nära samarbete med Boverkets systemansvarige för 
respektive system. Boverkets IT-enhet har sedan det tekniska ansvaret för att ändringen passar 
den tagna plattformen och den policy som Boverket har för plattformen. IT-enheten är de som 
analyserar den tekniska biten av beställningen så som att utveckla en kravspecifikation. 


Boverket genomför också egna förändringar på de system som de själva är ansvariga för. 
Förändringar av regler som finns implementerade i Skata genomförs av personal vid Boverket 
som endast jobbar med att förvalta regler som finns i deras system. 


På Flygt menar man att det främst är genom programmering i olika programkoder och system 
som regler underhålls och det blir därför naturligt att programmerarna sköter detta. Det är dock så 
att detta även sköts av underleverantörer men det gäller främst när reglerna finns i deras inköpta 
system. 


6.4 Vilka typer av Rule Repositories (RR) har organisationerna? (1d) 


Ingen av de båda kommunerna har någon form av RR. Flygt har inte heller något RR men de har 
en lagringsenhet där regler för information finns. På Flygt uttalar intervjupersonen även en 
önskan att i framtiden implementera ett RR. Reglerna på Flygt och i kommunerna finns spridda i 
programkod och/eller i databaser. Dokumentationen för dessa är dålig vilket medför att reglerna 
är svåra att finna. Det står klart att en enskild lagringsenhet för regler borde finns. 


I Emmaboda kommun säger de sig inte ha speciellt många regler implementerade och att de 
därför är överblickbara men det framkommer samtidigt att man har regler som begränsar 
användares rättigheter implementerade på flera ställen och i olika system. Detta är anledningarna 
till att de inte anser sig behöva något RR eller liknande. 


Boverket har heller ingen RR där alla BR finns samlade och detta anses inte vara ändamålsenligt. 
Detta för att Boverket beskrivs ha en väldigt differentierad verksamhet med olika system som är 
utvecklade för olika delar. Eftersom Boverket har flera olika system som har anpassats till att 
understödja olika delar av verksamheten är också reglerna för de olika verksamhetsdelarna 
uppdelade i olika system. Regler för löner i lönesystemet och regler för bidrag i Skatan och så 
vidare. Närmast en RR kommer Boverkets system Skatan som faktiskt innehåller alla regler för 
beräkning av bidrag. Men det finns alltså ingen samlad bild över alla regler hos Boverket heller. 


6.5 Är reglerna medvetet implementerade? (1e) 


I de båda kommunerna är regler som styr användares rättigheter och tillgång till information med 
mera strukturerade på ett medvetet och tydligt vis. Vissa regler finns i databaser och även här är 
medvetenheten och kontrollen också högre. I övrigt sker implementeringen manuellt och olika 
beroende på vilka system det gäller. Det finns i de senare fallen inte någon strikt struktur. 
Systemägare och systemförvaltare avgör från fall till fall vilka regler som implementeras och hur. 
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På Flygt har de bättre kontroll över sina regler men även om de är medvetet implementerade 
finns det ingen stark struktur över hur de implementeras. Där finns även en stor variation av 
programspråk där reglerna finns implementerade. 


Boverket har både medvetet implementerade regler och implementerade regler som de är 
omedvetna om. Boverket beskriver att regler som ska styra verksamheten, så som bestämmelser 
och regler för bidrag egentligen inte är något man kan bestämma över om de ska implementeras 
eller inte. För att exempelvis ett bidrag ska kunna beviljas måste samtliga regler för bidragen vara 
implementerade i systemen för att ärendet ska kunna hanteras. Detta beror på att länsstyrelserna 
också administrerar olika ärenden i systemen. Samtliga regler för bidrag måste därför 
implementeras på rätt sätt för att någon ska kunna beviljas ett bidrag. 


Boverket har också egna regler som begränsar eller validerar vad som ska kunna matas in i 
systemen. När det gäller dessa valideringsregler som finns implementerade i systemen som 
programkod är det Boverket som själva avgör till vilken nivå som användare av systemen ska 
begränsas i sin inmatning. Detsamma gäller även de e-tjänster som Boverket håller på att 
utveckla. De jobbar mot att en ansökan om ett stöd ska kunna ske elektroniskt utan någon 
pappershantering. I dessa elektroniska ansökningar sker validering av uppgifterna direkt i 
ansökningsformuläret i webbläsaren. Här beskriver intervjupersonerna att det är viktigt att inte ha 
en för hög grad av validering, att man inte kan styra den sökande i alltför hård grad, då det finns 
risk att bidragsansökaren kanske ger upp efter halva formuläret. Därför arbetar Boverket med att 
försöka hitta en lämplig nivå av uppgiftsvalidering som systemet ska genomföra för att förmå 
ansökare att använda sig av e-tjänsten istället för att ge upp, skriva ut den och sen fylla i den för 
hand. Detta är väl medvetna implementeringar som görs direkt i programkoden för 
ansökningsformulären. 


Samma sak gäller också i informationssystemet för energideklarationerna på Boverket. För att 
energideklarationerna ska anses vara fullgoda krävs det att vissa områden i en byggnad måste 
besiktigas. Olika värden måste tas fram och läggas in på rätt plats i ansökan innan den levereras 
in till Boverket. I detta arbete är besiktningsmännen styrda så att de måste fylla i vissa uppgifter 
på rätt sätt i ansökningsformuläret för att de överhuvudtaget ska kunna lämna in 
besiktningshandlingen och få den så kallade lappen i trappen, alltså resultatet av besiktningen. 
Och även här är det Boverkets medarbetare som bestämmer hur hård styrning det ska vara på de 
uppgifter som får skrivas in i systemen vilket också görs för att få så rättvisa resultat som möjligt. 
Detta är också exempel på väl medvetna implementeringar som har gjorts av Boverket. 


Även Bofink, som används för att administrera bidragsansökningar, innehåller olika 
valideringsregler för hur informationen ska skrivas in. Det sker både för de enskilda 
bidragsansökarna samt för de som handläggar ärendena. För att Boverket ska kunna genomföra 
uppföljningar av bidragen är det många obligatoriska uppgifter som måste skrivas in i systemet 
för att det ska finnas ett så komplett underlag som möjligt. Underlaget används sedan för att ta 
ställning till om en ansökning ska beviljas eller inte. Hur komplett detta underlag ska vara har 
Boverket därmed möjlighet att styra över genom att implementera olika regler för de olika 
formulären. Också alla bestämmelser för bidragen som är implementerade i Skatan är att se som 
en väl medveten och evaluerad implementering av BR. 
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Därutöver beskrivs flera implementerade regler som förekommer i det dagliga arbetet som 
Boverkets personal inte är speciellt medvetna om. Boverket är vad Peter Thorsson kallar för en 
utredande myndighet. Boverket utreder olika frågor, svarar på överklaganden, omprövar beslut 
och så vidare. Dessa arbetsprocesser måste genomföras på speciella sätt och styrs därmed också 
av BR. Vissa av dessa BR är implementerade i diverse informationssystem som finns till för att 
understödja det dagliga arbetet men som Boverket inte i högre grad är medvetna om, vilket kan 
utläsas ut citatet nedan. Där finns exempelvis regler om vem som har tillgånga till vissa mappar 
och så vidare. 


”...vi är en utredande myndighet, vi utreder olika frågor, vi svarar på överklaganden 
och omprövar beslut och så. Och där är det ju mera, alltså själva den verksamheten 
är det ju mera stödsystem som kommer in. Så att vi skriver i word och officepaketens 
system och så. Och då finns det ju en hel del regler som du måste hålla i huvudet, när 
måste ett överklagande komma in och när ska jag svara och vad är det för gränser 
och så, det kan ju också styras i ärendehanteringssystemen med stöd och så men det 
har vi ju inte alltigenom...” (Peter Thorsson, Boverket) 


Utöver detta är det också mycket av verksamheten som inte är implementerad i något system men 
som också innehåller BR. På grund av undersökningens avgränsningar går vi inte in på detta här. 
Sammantaget har Boverket många medvetna implementeringar av BR i IT och IS men också 
många omedvetna. 


6.6 Är reglerna inbäddade i programkod eller separerade från 
systemen? (1f) 


Inom de båda kommunerna finns reglerna främst implementerade i olika databaser eller 
mjukvaror som bygger på databaser. I Emmaboda har man lagt ut implementeringen av vissa 
regler på en underleverantör och det är osäkert hur dessa regler implementeras i systemen. På 
Karlskrona kommun anger man SQL som främsta stället där regler implementeras och reglerna 
finns i dessa fall inbakade i databaskoden. På Flygt finns reglerna i olika programkoder och i 
databaser, reglerna är alltså implementerade i olika programkoder och man framhåller att det 
saknas en tydlig gräns mellan kodade regler och övrig kod. På Flygt dokumenterar man dock en 
del regler utanför koden men reglerna finns ändå kvar i koden. Denna dokumentation gäller 
främst sådana regler som styr processer. Boverkets regler finns också inbäddade i programkod för 
olika system eller i databaser. Boverket har också implementerat vissa stödfunktioner såsom 
Skatan som möjliggör för anställda att få en bättre och enklare förvaltning av reglerna. 


6.7 Hur beskrivs BR i organisationernas terminologi? (1g) 


Terminologin varierar men hos alla organisationer nämns verksamhetsregler och affärsregler som 
termer som beskriver BR. På Flygt nämner man även processer och processbeskrivningar som 
varianter på BR. Inom kommunerna tycker man även att kommunernas mål och visioner kan 
innefattas i begreppet. 
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På Boverket har de inte fört någon diskussion över vilka termer som ska användas i det dagliga 
arbetet. Vilka termer som verkligen används beskrevs som något som är en naturlig del i själva 
arbetsprocessen. Det märks under intervjun på Boverket att intervjupersonerna är vana vid att 
prata om regler och de nämner dessutom ord som regelprogrammering när de pratar om hur 
regler ska implementeras. De beskriver att själva begreppet regler är ett känt begrepp hos 
Boverket eftersom hela Boverkets verksamhet bygger på att tillämpa lagar och regler i samhället. 
Detta eftersom Boverket skriver alla landets byggregler och egentligen är den myndighet som 
talar om för en person hur den får bygga ett hus, från minsta lilla spik och uppåt. Vanligast sägs 
termen verksamhetsregler vara när de pratar om regler som styr hela deras verksamhet. När de 
pratar om externa regler så som lagar och förordningar och så vidare används termen 
bestämmelser. Bidragen som hanteras med systemen Bofink och Skatan kallar Boverket för 
statliga stimulanser. 


Eftersom Boverket inte bygger sina system själva har de haft ömsesidiga utbildningar 
tillsammans med sina konsulters personal. Detta har gjorts eftersom de märkte när de började 
bygga systemen att anställda vid Boverket använde en helt annan terminologi än vad de 
kontrakterade IT konsulterna gjorde. Intervjupersonerna från Boverket beskrev också att det är ett 
problem för det dagliga arbetet om det uppstår kommunikationsproblem på grund av att 
personerna inte använder samma begreppsapparat. 


Sammantaget finns hos dessa fyra organisationer ingen skarp linje som skiljer ut vad eller vilka 
BR som finns i organisationen och hur dessa skiljer sig från övriga regler. Även om det på 
Boverket finns en klart tydligare bild av regelförvaltningen än hos de andra tre. 


6.8 Övriga intressant fakta som framkommit. (2) 


Två av de fyra tillfrågade organisationer kände inte till begreppet BR medan alla gärna ser en 
bättre kontroll över sina regler. Kontrollen gäller med avseende på alla plan, implementering, 
uppdatering, RR med mera. Alla organisationer anser också att ett BRMS skulle kunna göra nytta 
i deras organisation. Både Emmaboda kommun och Flygt funderar i banor som hur man ska 
hantera regler på ett bra sätt. Att få reglerna nedskrivna och separerade från programkod 
framhålls också som önskvärt. På Karlskrona kommun säger man sig sakna regler som är klara, 
väldefinierade och strukturerade men man saknar även regler framtagna i samarbete med 
ledningen inom de olika områdena. 


Vid frågan om de kände till begreppet Business Rules sade Peter Thorsson från Boverket att de 
hade hört talas om begreppet Business Rules och beskrev att det betydde verksamhetsregler eller 
affärslogik. Det beskrevs som regler som styr verksamheten. När det gällde begreppet Business 
Rules Management System (BRMS) svarade man från Boverkets sida att man hört begreppet 
någon gång tidigare, men att man i nuläget inte fört någon diskussion om att använda det. De 
uttryckte vidare att ett BRMS mycket väl skulle kunna passa in men att det var något som de inte 
hade ägnat några djupare funderingar över. Man ansåg det ändå viktigt att hålla koll på hur alla 
reglerna är implementerade i databasen Skatan och i övrigt. 
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Vid frågan om intervjupersonerna från Boverket skulle vilja förbättra sin förvaltning av regler på 
något sätt svarade de att de skulle behöva någon som har en övergripande kontroll över hur regler 
ska implementeras. De upplevde att förfarandet av hur de använder implementerade regler i sin 
dagliga verksamhet fungerar ganska bra, men att det däremot saknades en översyn och att det 
fanns brister, exempelvis implementeras inte alltid regler vid rätt tillfälle och så vidare. De 
beskrev hur de försökt att ta ett steg i rätt riktning genom att applicera en IT-enhet som har 
kontroll över samtliga system inom Boverket och ser till så att de passar in i verksamheten. Man 
menade att en bättre övergripande översyn är önskvärt för att minska risker, liksom vikten av att 
man inte arbetar med samma saker på mer än ett ställe. Vidare sades det att ett management 
system för regler kanske hade varit mycket användbart men att de inte tagit några steg i den 
riktningen. 


Ett problem som beskrevs av intervjupersonerna från Boverket gäller deras 
beställningsförfarande. I beställningsförfarandet beskriver Boverket de regler de har fastställt för 
att styra hur beställningar ska genomföras. Boverkets beställningssystem heter prime portal vilket 
också är styrt av regler för behörigheter. Exempelvis är det bara vissa personer som har rätt att 
göra vissa beställningar. I beställningsförfarande har Boverket en regel som säger att de ska 
kunna följa upp ett uppdrag som de har lämnat till en konsult och se vad som har hänt från början 
till slut. Om Boverket själva eller någon annan ämnar göra en revision av Boverkets verksamhet 
måste det finnas, svart på vitt, vad som har hänt under ett specifikt uppdrag. Om exempelvis en 
förändring av Boverkets system har genomförts med hjälp från externa konsulter vill de att detta 
ska finnas nedtecknat, till exempel uppgifter om vilka de är, när man började genomföra 
förändringar i systemet med mera. 


Hur Boverket går tillväga för att avgränsa vilka regler som ska implementeras förklarar 
intervjupersonerna beror på varifrån reglerna kommer, om det är externa eller interna regler och 
så vidare. Boverket har inga generella regler för hur avgränsning skall göras av vilka regler som 
ska implementeras eller inte. Istället har Boverket ett övergripande dokument som kallas 
regleringsbrevet i vilket regeringen beskriver alla de områden och uppdrag som Boverket ska 
utföra. Detta regleringsbrev utmynnar i en mängd olika dokument som beskriver respektive 
verksamhetsområde. Det kan till exempel vara lagar och förordningar som måste implementeras 
för att de ska få genomslag i den övriga verksamheten. Detta eftersom verksamheten är uppbyggd 
av olika informationssystem som styr det dagliga arbetet. De regler som man väljer att 
implementera är de som för det första går att implementera det vill säga, att de stödsystem som 
finns på Boverket klarar av att hantera regeln på ett tillfredsställande sätt genom att den kan 
appliceras som en naturlig del i det daliga arbetet. För det andra måste vissa regler 
implementeras, såsom bestämmelserna i Skatan, för att de ska kunna få genomslag vid 
exempelvis utfärdande av bidrag. Vidare utarbetar också Boverket projektplaner vilka också kan 
innehålla många regler. Dessa går Boverkets anställda igenom för att undersöka hur vissa av 
reglerna ska implementeras i deras system. Många av reglerna blir därmed kvar i pappersform, 
exempelvis dokument, vilka Boverket måste rätta sig efter i sitt dagliga arbete. 


Intervjupersonerna från Boverket berättade även att verkställandet av regeringens förordningar 
också är tidsbestämt. Detta medför att Boverket också måste tillämpa regler vid speciella 
tidpunkter och datum. Om en ny förordning ska träda i kraft exempelvis den första juli måste 
Boverket ha uppdaterat systemen till det datumet så att de klarar av att hantera de nya 
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bestämmelserna. Systemen kan alltså inte uppdateras i förväg innan lagen eller förordningen har 
trätt i kraft. 


Ett annat exempel som ges på hur regler underhålls och uppdateras men som inte är helt 
implementerade i programkoden för något system är när Boverkets säkerhetspolicy beskrivs. 
Säkerhetspolicyn styr, kort beskrivet, vad Boverkets anställda samt utomstående får lov att göra i 
Boverkets system. När anställda genomför ändringar i säkerhetspolicyn finns där ett 
underliggande dokument som beskriver för användaren vilka övergripande regler som finns inom 
Boverket. När en ändring görs i säkerhetspolicyn är den ändringen samtidigt en beställning om att 
samma förändring måste ske i Boverkets övergripande verksamhetsunderstödjande system. 

Själva beställningen om att systemet måste uppdateras sker alltså automatiskt. 
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7. Diskussion 


I detta kapitel diskuteras hur automatiserade BR förvaltas inom de organisationer vi har 
undersökt. Detta diskuteras och reflekteras över genom att knyta an till redovisning av data i 
litteraturgranskningskapitlet, kapitel 3. ”Business Rules”. 


7.1BR & Business Models 


BR behöver integreras med andra organisatoriska inslag så som verksamhetsaktiviteter, processer 
och verksamhetsmål (Morgan, 2002). Det första steget kan vara att inkorporera BR och BRA i 
organisationens business models (BR-Manifestet, 2008). Detta görs i syfte att klarlägga den 
underbyggande verksamhetslogik som bygger upp organisationens verksamhet och styr det 
dagliga arbetet (Morgan, 2002). Ingen av våra fallorganisationer hade vidtagit några åtgärder för 
att genomföra detta. Intervjupersonerna från Boverket hade hört talas om begreppet BR förr men 
hade inga tankar om att ytterligare assimilera vad vi kallar BR med deras business model. 


Hos alla våra fallorganisationer är IT och IS en stor del av den dagliga verksamheten. IT hade 
anpassats till att understödja organisationernas verksamheter och det uppfattades som en resurs. 
Detta beskriver Hedman & Kalling (2002) som en av de viktigaste anledningarna till att business 
models används. IT och IS har förmodligen redan, på ett eller annat sätt, letat sig in i våra 
fallorganisationers business models för att alstra förtjänst eller utveckling. Intervjupersonerna 
från Boverket var vana vid att prata om regler och det reflekterades över hur IT och IS kunde 
användas för att på bästa möjliga sätt förvalta sina regler. Vad BR kan tillföra organisationerna är 
att genom regler representera den kunskap och de bestämmelser som bygger upp verksamheten 
(Morgan, 2002). Organisationernas aktiviteter, processer och mål med mera kan med BR 
uttryckas så att både verksamhetspersonalen och IT-människorna förstår dem (Morgan, 2002). 
Värdet av BR är att med detta sammanfläta organisationernas IS och IT med verksamheten, 
snabba upp beslutsprocesser inom EDM samt göra verksamhetslogiken synlig och möjlig att 
snabbt förändra (von Halle, 2001). Ett första steg mot att ta del av vad BR kan tillföra är att göra 
BR till en aktör i organisationens business models. Genom detta medverkar BR i planeringarna 
om hur IT och IS kan användas för att förvalta regler. 


7.2 De olika rollerna vi fann i organisationerna. 


Som nämndes i kapitel 3.15 är det viktigt att involvera de som använder BR i sitt dagliga arbete i 
BR-förvaltningen. I kommunerna finns denna koppling då det gäller många av de olika 
förvaltningarnas, avdelningarnas, BR-förvaltning. Men någon eller några som har rollen som BR- 
Steward saknas genomgående i de fyra organisationerna. Det ska dock nämnas att det inom 
Boverket finns tendenser till att olika personer får ansvar för underhåll och uppdatering av några 
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bestämda BR men det är långt ifrån alla BR som behandlas på detta sätt. Med detta menar vi att 
det finns de som har en roll som liknar en BR-Stewards inom Boverket när det gäller ett antal av 
de regler som de använder. Men det vanligaste inom alla fyra organisationerna är att BR 
underhålls och uppdateras av de som jobbar inom IT och IS samt för tillfället är mest tillgängliga. 
Andra uppgifter som faller på en BR-Stewards bord är att se till att BR sparas och dokumenteras 
på rätt sätt och plats men även att BR som blivit inaktuella elimineras. Det finns inte någon som 
uttalat har dessa roller inom någon av de fyra organisationerna utan detta är moment som faller 
på de inom IT- och IS-avdelningarna som för tillfället är lediga. Sparande, dokumentering och 
eliminering sker därför på ett ganska oplanerat sätt. Att det inte finns någon uttalad BR-Steward 
bidrar till att det finns svårigheter att hålla ordning på var och vilka BR som används. Därför är 
det också svårt att få konkreta exempel på BR som finns i organisationernas system. Boverket är 
som nämnt undantaget bland de fyra och de har god kontroll och bra dokumentering på många av 
sina regler. Det som beskrivs ovan är troligen en god bild av hur det ser ut i många svenska 
organisationer och det verkar mer vara regel än undantag att BR underhålls, uppdateras, 
implementeras och så vidare sköts helt eller delvis av underleverantörer. Dessa underleverantörer 
är många gånger även desamma som levererar och underhåller mjukvara och eller system till 
organisationerna. 


När det gäller roller som kan liknas vid en BR-analytikers (se kapitel 3.15) finns det uttalat 
sådana i de fyra organisationerna. Boverket är det bästa exemplet då de har ansvariga som 
ansvarar för att BR stödjer de system som används och att BR uppfyller de krav som är 
uppställda. De ansvariga, BR-analytikerna, inom Boverket har även till uppgift att finna BR i 
lagar och förordningar som kommer genom riksdagsbeslut med mera. Men i Boverket sköter 
dessa BR-analytiker även en BR-Stewards roll vilket gör att en kontrollenhet för BR försvinner. 
Därmed anser vi att BR-kvalitén riskerar att bli lägre. I kommunernas policy finns en 
bestämmelse att systemanalytiker och tekniker tillsammans med ägarna av systemen, oftast 
någon förvaltning inom organisationen, sköter BR-analytikerns roll genom processerna att 
förvalta BR. När dessa processer genomförts lämnas implementeringen och formuleringen över 
på systemteknikern eller någon programmerare inom eller utanför organisationen. Att denna 
formulering och implementering inte sker med stöd av en BR-Steward gör att BR blir svåra att 
finna och ofta ligger begravda i programkod. Vi anser att detta fenomen speciellt uppstår när 
uppgifterna utförs endast av programmerare och det inte är enkelt för övriga att tyda programkod 
eller ens finna de platser i koden där BR finns. 


Vi finner i de fyra organisationerna bara inom Boverket någon som kan sägas vara BR- 
Administratör. Inom Boverket finns det ett antal som ansvarar för olika delar av de BR som finns 
implementerade. De finns alltså de som har ett övergripande ansvar för de olika system som finns 
inom Boverket och de BR som finns i dessa system. 


7.3 Var finns BR 


Automatiserad regelidentifiering eller någon data mining har vi haft svårt att finna även om det 
med största säkerhet förekommer i någon form inom alla organisationer. Vad vi däremot funnit är 
att mycket av de BR som organisationerna har och använder finns implementerade i databaser. 
Det sker därför med stor sannolikhet någon form av data mining, sökning, i dessa databaser. 
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Organisationerna har uttalat att de har många av sina BR direkt implementerade i programkod 
och att dessa blir väldigt mödosamma att finna om de behöver uppdateras, elimineras och så 
vidare (Morgan, 2002). Att organisationerna saknar fungerande verktyg för regelidentifiering och 
data mining tillsammans med att mycket av BR finns i programkod skapar svårigheter i BR- 
förvaltningen. Det torde även bli ytterst kostsamt och ineffektivt att förvalta BR utan dessa 
verktyg och detta bidrar även till att skapa en rigidare organisation (Morgan, 2002). Att använda 
automatiserade regelidentifieringar och verktyg för data mining för att få kontroll över 
organisationens BR och därigenom skapa flexibilitet är viktigt i dagens föränderliga värld menar 
Morgan (2002). 


Att som dessa fyra organisationer ha mycket av sina regler i databaser är vanligt och Date (2000) 
förespråkar till och med detta sätt att implementera BR. Date skrev sin bok år 2000 och mycket 
har hänt inom området sedan dess och förfinade metoder har under tiden utvecklats. Men det är 
vanligt att man som i de två kommunerna behandlar mycket av sina rättigheter för användare i 
SQL eller liknande (Date, 2000). Vi tror också att det är vanligt i svenska organisationer att som i 
våra fallorganisationer förvalta användarbegränsningar manuellt och individuellt för varje 
användare. Det vore tids- och effektivitets-besparande om man på exempelvis Morgans (2002) 
vis konstruerade BR som sedan använder informationen i databaserna. Vi hittade inte någon 
sådan linje i organisationerna utom till viss del i Boverket. Inom Boverket har de som vi beskrivit 
en väl fungerande BR förvaltning inom vissa områden och de tänker även i banor kring RR och 
BRMS. Ett troligt scenario är att om inte Boverket haft bättre förvaltning av sina BR så hade 
organisationen varit mindre flexibel och tungrodd eller hade den åtminstone varit betydligt 
personalintensivare. Vad vi menar är att regeltäta organisationer måste ha en god BR förvaltning 
men att detta hade varit nödvändigt även utan IT- och IS-stöd. Vi anser att Boverket har en god 
organisation runt sin BR-förvaltning vilket vi diskuterar nedan med utgångspunkt i RMM. 


De använde även UML för att modellera system och förhållanden inom Boverket. Dessa UML- 
diagram kunde vara en utmärkt grund att bygga deras BR på. Morgan (2002) beskriver också 
vikten av att det finns en koppling vad gäller språk med mera mellan UML-diagramen och de BR 
som skapas utifrån dessa. Morgan påpekar också att det är bra att kunna utgå från dessa UML- 
diagram när man skapar BR. 


7.4 RMM & Fallorganisationerna 


Våra fallorganisationer hamnar på lite olika ställen i von Halles (2006) RMM. Vi tycker att denna 
modell tillsammans med Zachmans ramverk (som diskuteras i nästa kapitel) utgör en bra grund 
att diskutera organisationers förhållande till eller snarare förvaltning av BR. Eftersom 
organisationerna hamnar på olika nivåer i RMM kommer vi att diskutera dem var för sig. 
Kommunerna kommer dock att behandlas under samma rubrik då de fungerar på ett likartat sätt i 
sin BR-förvaltning. Genom att använda von Halles (2006) RMM kan organisationerna ordnas till 
en nivå av BR-mognad i modellen. Genom att ordna en organisation i RMM kan 
organisationernas medlemmar också utvärdera vad som behövs eller saknas för att uppnå en 
högre nivå av BR-mognad. Detta för att RMM ger en bild av de bedömningsgrunder som krävs 
för att konceptet BR ska integreras i organisationen. Organisationerna kan utarbeta ett 
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beslutsunderlag som kan användas för att vägleda arbetet med att tillämpa de teknologier, 
tekniker och metoder som BR är i verksamheten. 


7.4.1 Emmaboda och Karlskrona kommun, nivå 0-1. 


Kommunerna hamnar i någon av de första två nivåerna det vill säga mittemellan en 
omedvetenhet om BR och att vetskapen om BR-förvaltning börjar finnas i organisationen. I dessa 
organisationer är det svårt att förutse hur en förändring i BR kommer att påverka de olika 
systemen och var denna förändring skall utföras. Detta leder till att BR-förvaltningen blir 
tidskrävande och består mycket i att söka och ändra kod i olika databaser och programkoder. Det 
finns även mycket kunskap om BR som i dessa regler är tacit. Då menar vi att många BR och 
deras struktur finns i ”huvudet” på IT-avdelningarnas medarbetare men även ute hos de olika 
förvaltningarna. Det verkar dock som om det förts diskussioner om att styra upp BR- 
förvaltningen inom åtminstone Emmaboda kommun. Problemet de säger sig ha i Emmaboda är 
att de är en så liten organisation och inte har ekonomi att avdela en tjänst för denna hantering. 
Förvaltningen av BR inom dessa organisationer är mycket tidskrävande och risken för fel eller 
konflikter i BR är uppenbar. I kommunerna har man dessutom lagt ut BR- hantering som styr 
många användares, så som elevers och skolpersonals rättigheter i systemen och därmed minskar 
dessa problem, men deras egen kontroll över dessa BR minskar också. 


7.4.2 Flygt, nivå 2 


Även om de på Flygt verkar vara medvetna om BR och dess betydelse så har man svårt att 
förutse hur en förändring av BR kan slå igenom i systemen. Man säger att BR och processer är 
styrda och möjliga att analysera och de har bra kontroll och medvetenhet över sin BR-förvaltning 
på dessa sätt. Det saknas dock någon form av BRR då de fortfarande har BR gömt i olika 
programkoder och i databaser. De framhåller att de har vissa BR, främst de som styr processer, 
nedtecknade i dokument. Då vi inte har sett något exempel på hur dessa dokument ser ut så kan vi 
inte säga säkert men vi antar att det innehåller nedtecknade regler, BR. Det kvarstår då 
fortfarande att finna BR i kod för att kunna uppdatera dem och som vi påpekat tidigare är detta ett 
tidsödande arbete. Flygt har kommit så långt att de definierar, analyserar med mera, BR men de 
saknar IT- och IS-verktyg, till exempel BRMS och BRR, för att strukturera BR-förvaltningen. 


7.4.3 Boverket, nivå 3-4 


Boverket har kommit en bra bit på vägen i sin BR-förvaltning och hamnar på en nivå någonstans 
mellan tre och fyra i RMM. Det är främst inom vissa delar och system som Boverket kommit 
långt. I dessa system har Boverket förmågan att analysera men även finna BR på ett enklare sätt 
än i de övriga tre organisationerna. BR fungerar också på ett mer automatiserat sätt än i de övriga 
och man ändrar här regeln på ett ställe. BR finns separerat från de övriga systemen och anropas 
på så vis utifrån, det saknas dock ett uttalat BRR som skulle öka nyttan ännu mer. De har inom 
Boverket också som standard att testa BR och hur de fungerar med övriga system innan BR 
automatiserats, vilket höjer säkerheten betydligt. Det finns också BR hos Boverket som ligger 
gömda i olika programkoder och databaser. Man har inom organisationen kommit långt inom 
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många områden medan man inom andra inte kommit mycket längre än de tre övriga 
organisationerna. 


Nivå 0 Nivå 1 Nivå 2 Nivå 3 Nivå 4 Nivå 5 
Omedvetenhet Vetskap Agility Konsekvens Förutsebarhet Förvaltning 
Minimum Värde för verksamheten Max 
Höga Lägre Svag förmåga att | Förmåga att Effekten av Effekten av 
förändrings- förändrings- förutse förutse förändringar är förändringar är 
kostnader. kostnader. förändringars förändringars förutsebar. förutsebar, 
Ingen förmåga | Fortsatt dålig effekt. Regler effekt är organisationen 
att förutse förmåga att och processer förbättrad. har god integritet. 
förändringars förutse effekten | möjliga att Automatiserad 
effekt. av förändringar. | analysera. regelanalys som 

Analys av regler reducerar 

är möjligt men kostnader. 

innebär vanligen 

manuellt arbete. 


Kommunerna Flygt Boverket 


Tabell 7.1: Fallorganisationerna och RUM 
Tabell 7.1, som är en förenkling av RMM, visar var vi bedömer att organisationerna befinner sig i 
RMM. (RMM finns i sin helhet på sidan 35) 


7.5 BR i Zachman framework 


Zachman framework är som vi beskriver i kapitel 3.7 ett ramverk som kan användas till att förstå 
och reflektera över IT och IS relation i organisationen. Genom att använda de fakta och data som 
de som svarat på våra frågor delat med sig av kan vi också få en övergripande bild av hur våra 
organisationer förvaltar sina BR i förhållande till ramverket. Vi har tagit ut de celler vi tycker är 
relevanta (två stycken i kolumn 4 och alla i kolumn 6) i ramverket och diskuterar dessa i 
förhållande till de fyra organisationerna. 


7.5.1 Kollumn fyra och sex i Zachmans ramverk i förhållande till BR-förvaltning. 


I kommunerna och då speciellt i Emmaboda lägger de i sin beskrivning av BR i mål och visioner. 
Dessa finns främst beskrivna i ”varför”-kolumnen i ramverket och i de två översta raderna. Även 
Boverket är styrt av de lagar och förordningar som deras uppdragsgivare, staten, beslutar. Många 
av dessa mål, visioner och så vidare skulle med hjälp av till exempel Morgans (2002) koncept 
implementeras som BR och därifrån nyttjas för att styra systemen inom organisationerna. Detta 
skulle också fungera inom Flygt men de talar inte lika tydligt om de mål med mera som styr 
verksamheten i dessa sammanhang. I de övriga fyra raderna i ”varför”-kolumnen har alla 
organisationerna en relation till de olika koncepten men dessa relationer är tydligast hos 
Boverket. Hos Boverket har man strategier för att modellera, designa, specificera och 
implementera och upprätthålla BR, alltså en tydlig BR-förvaltning. Som vi nämnt tidigare gäller 
detta i några inom Boverkets utvalda system. På detta sätt har Boverket strukturerat sin BR- 
förvaltning mycket tydligare än inom de övriga organisationerna. Inom de tre övriga 
organisationerna styr BR inom detta område likväl som inom Boverket men dessa tre har inte 
samma kontroll och struktur på BR-förvaltningen. När det sedan gäller ”vem”-kolumnen är BR 
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tydligt involverat i raderna tre och fem. Det är här organisationerna behandlar användare, deras 
rättigheter och så vidare. Det verkar som det inom alla fyra organisationer finns riktlinjer som 
kunde utvecklas till BR för hur dessa områden ska behandlas. Det verkar dock inte som 
organisationerna har kommit så långt i sin BR-förvaltning att de kan applicera detta. Det är 
fortfarande så att användarnas rättigheter, begränsningar med mera sköts manuellt istället för att 
det exempelvis finns olika profiler av användare i BR. Ett konkret exempel skulle kunna vara: 


R11 En registrerad student måste få följande rättigheter i systemet: 
- En gigabyte utrymme på servern. 
- Inloggningsrattigheter pa studentdatorer. 

1 Vad 2 Hur 3 Var 4Vem 5 Nar 6 Varför 
Omfang, Mal / Lista av for Lista av processer / Omraden, platser, Lista av avdelningar, | Händelser och | Verksamhetens 
Syfte organisationen | organisationen dar organisationen | individer med mera. | förlopp i mal och 

viktiga saker. | utför. verkar. verksamheten. | strategier. 
Verksamhets Relationer Modell över Nätverk. Modell med Verksamhetens | Verksamhetsplan. 
modell mellan verksamhetens individers roll, tidsschema. 

entiteter. processer. kunnande och 

säkerhets aspekter. 

IS-modell Datamodell Dataflödesmodell | Distribuerade Individer och avd. Entiteters BR-modell. 

med länkade och applikations system. deras data, roller och | livscykel / 

entiteter. arkitektur. åtkomstbegränsningar. | processtruktur. 
IT-modell Dataarkitektur. | Systemdesign. Systemarkitekturen. | Granssnitt och I BR-design. 

sdkerhetsdesign. kontrollmoment. 

Detaljspecifikation | Datadesign, Applikationsdesign | Natverksarkitekturen | Säkerhets- och Tidsschema. BR-specifikation 

lagringscentral. | av delar. atkomstbegransningar. i programlogik. 
Funktionellt IS. Konvertera Korbara program. | Kommunikations Utbildad personal. Verksamhets Upprätthållande 

data. forum. händelser. av BR. 


Tabell 7.2: Zachmans ramverk 

Zachmans ramverk är författarnas tolkning med stöd i litteraturen. De delar där BR är speciellt 

signifikant är markerade med grått ju mörkare grå desto djupare effekt av BR. (Hay, 1997 och 
1998; von Halle, 2001; Morgan, 2002; Ross, 2003; Zachman Framework, 2008) 


7.5.2 Övergripande diskussion av BR:s betydelse i övriga delar av Zachmans ramverk. 


- 1. Vad: (Data) Härifrån kommer vokabulären som sedan används för konstruera de regler 
som implementeras. Boverket, Kommunerna och Flygt har alla data i olika former som 
behöver processeras på något sätt. Boverket har bidrag och byggregler, kommunerna har 
data för skolelever och Flygt har data för produktion och försäljning av pumpar med 


mera. 


- 2, Hur: (Funktion) Alla våra fallorganisationer har processer de utför. Utmärkande för 
Flygt är att det är en industri och att BR styr många processer inom industrier. 


- 3. Var: (Nätverk) Kommunerna har en ganska centraliserad organisation rent geografiskt 
men det är ändå många olika förvaltningar, skolor med flera som ingår i deras nätverk. 
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BR kan då användas för att styra kommunikation, åtkomst med mera inom detta nätverk. 
Flygt har en organisation som har kopplingar runt om i världen och BR borde kunna 
underlätta flöden mellan organisationens olika delar. Detta gäller även för boverket. 
Boverket genomför sin verksamhet på uppdrag av Sveriges regering och måste rätta sig 
efter deras bestämmelser. Olika regeringsdepartement skriver lagar och förordningar som 
Boverket måste skriva om till kompatibla BR vilka kan implementeras i deras 
datorsystem. Denna kommunikation av regler skulle kunna underlättas genom att skriva 
konkreta och formella BR som sedan kommuniceras mellan boverket och departementen. 


- 5, När: (Tid) Alla fyra organisationer borde kunna formulera BR som styr händelser, 
tidsscheman, livscykler och andra tidsstyrda aspekter. 


7.6 BRA & Struktur av BR 


Av våra fallorganisationer var det endast Boverket som använde sig av något som liknar 
anvisningarna som förespråkas i BRA. Boverket stod ut från övriga organisationer genom sitt 
system Skatan som uteslutande användes för implementering av regler, BR, gällande bidrag. 
Dessa BR var implementerade i en databas och systemet hade utvecklade hjälpfunktioner för att 
underlätta förvaltning av BR. I övrigt implementeras inte BR enligt de anvisningar som finns i 
BRA inom någon av de fyra fallorganisationerna. BR fanns inte heller separerade från systemen 
genom ett formaliserat regelspråk som kan liknas vid Morgans (2002) teorier för BR- 
konstruktion. Boverkets system Skata kan ses som en blandning av en egenutvecklad BRE och 
BRR. Att vi kan likna Skatan vid dessa beror på att Skatan är ett regelverk med alla bidragsregler 
separerade från systemens programkod. Dessutom är de BR som finns i Skatan skrivna med ett 
formaliserat språk. Varje specifik BR i tabellerna är länkad till den programkod som BR var 
menad att styra. Systemet Skatan underlättade för användarna att genomföra BR-förändringar. 
Regelförändringarna genomfördes likväl direkt i programkoden fast med hjälp av deras variant av 
BRR. Genom att välja vilken BR de ville förändra i sitt BRR blev de direkt länkade till det ställe i 
programkoden som regeln fanns implementerad. Även om Boverket hade vissa BR samlade i ett 
BRR hade ingen av våra fallorganisationer en övervägande del av sina BR samlade i ett BRR. 


Det uttrycktes en önskan av samtliga intervjupersoner att det behövdes en bättre förvaltning av 
BR. Det saknades en översyn över alla regler och på Boverket fanns brister i riktlinjer för hur 
regler ska implementeras. von Halles (2001) fyra principer som presenterades på sidan 19 löd: 


e Separera organisationens regler från den övriga verksamheten. 

e Externalisera reglerna sa att alla vet vad reglerna säger. 

e Gora reglerna spårningsbara sa att organisationens medarbetare vet var reglerna finns och 
varifrån de kommer. 

e Positionera reglerna för förändring. 


Inom alla våra fallorganisationer var BR inbäddade i olika typer av programkod. Vi fann alltså att 
våra fallorganisationer inte förvaltade BR enligt von Halles (2001) fyra principer. När regler 
inom våra fallorganisationer ska ändras inleds ett arbete med att söka igenom kod eller databaser 
för att finna, uppdatera eller ta bort regler. Gemensamt för Flygt, kommunerna Emmaboda och 
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Karlskrona är att underhållet till största del sker lokalt och manuellt i olika system och på olika 
avdelningar. BR externaliseras inte och skrivs inte enligt Morgans (2002) teorier eller någon 
annan BR-mall, med undantag från Boverkets system Skatan. 


UML-klasser 


Implementering 


Definierar Utjämnas Översätts 


termer för till till 


— 
BR Påstående 


Formella 
BR 


4 Lagras i 


BR 
Databas 


På Boverket strukturerar de sina BR på ett sätt som kan likna Morgans (2002) teorier (Figur 7.1). 
Boverket använder variabler som finns inom deras datamodeller för att strukturera hur de skriver 
sina BR i systemet Skatan. Programkoden är implementerad med hjälp av variabler som är 
namngivna efter de benämningar och begrepp som finns inom de bestämmelser för bidrag som 
kommer till Boverket. Detta kan ses i figurerna 6.4: Hjälpfunktion i Skatan (sidan.57) som visar 
en lista av variabler som används för att implementera BR i programkod och 6.3: Skatan + 
förklaring hur regelkoden uppdateras (sidan.56) vilken visar ett kodutdrag som innehåller de 
olika variablerna som BR är implementerade med. Regeltabellerna i Skatan liknar en BR-Databas 
(Figur 7.1 ) där alla BR för bidrag finns lagrade. Vad som saknas är tydligt skrivna BR i en BRR 
som är lätta att förstå och sammankopplade med implementerade BR. En förändring av en BR i 
BRR kan automatiskt ge medarbetarna som jobbar med BR-förvaltningen precisa riktlinjer för 
hur programkoden måste förändras för att implementera BR-förändringen. Det saknas 
möjligheter att kunna spåra förändringar som har gjorts av BR och en BR-mall som används för 
att alla BR i Skatans tabeller ska utformas på samma sätt. Intervjupersonerna från Boverket anser 
att det behövs riktlinjer för hur regler ska implementeras. Genom att strukturera formella BR 
enligt figur 7.1 som enkelt kan översättas till implementerade regler i programkod kan 
organisationens medarbetare sammankoppla programkoden med formellt skrivna BR. De BR 
som Boverket väljer att implementera är de som stödsystemen, exempelvis Skatan inom 
Boverket, klarar av att hantera. Man låter alltså reglernas struktur och den systemarkitektur som 
finns få avgöra hur BR ska implementeras och IT/IS stödet anpassas inte efter verksamheten till 
fullo. Vi har funnit några svårigheter som beskrivs i nedanstående lista: 


Datamodeller 


Definierar 
struktur för 


—> 


Lagras i 


—> 


BR-mall 


Figur 7.1: BR struktur 


e Lagar och förordningar. Boverket far manga av sina föreskrifter från regeringen. Dessa 
föreskrifter som bland annat innehåller regler för hur boverket ska driva sin verksamhet 
får boverket av naturliga skäl inte förändra så att de passar den systemarkitektur som 
finns. Nationella lagar och regler som är uppsatta av regeringen får oftast inte förändras 
av lokala myndigheter utan kontroll från högre samhälleliga organ. Boverket kan därmed 
ha svårt att förändra eller skriva om alla dessa till kompatibla BR som de sedan kan 
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implementera. Men vi anser det vara fullt möjligt att göra detta med Morgans (2002) 
regelmönster. 


Offentlig IT-standardisering. Boverket och till viss del även kommuner måste också rätta 
sig efter de standarder som Sveriges regering har satt upp. För att information och 
kommunikation ska kunna samordnas i Sverige behövs standarder som alla myndigheter 
följa. Detta för att information måste kunna skickas mellan myndigheterna på ett effektivt 
sätt. BR och BRMS inom dessa myndigheter måste då fungera kompatibelt med de andra 
nationella system som finns. 


Kostnader. Att genomföra de verksamhetsförändringar som krävs för att tillvarata BRA i 
verksamheten kan bli dyrt. Eftersom denna uppsats inte behandlar 
verksamhetsförändringar och eventuella kostnad/effektivitets kalkyleringar väljer vi att 
endast nämna detta. 
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8. Avslutande reflektioner och svar på 
forskningsfrågor 


I problemdiskussionen av denna uppsats, kap 1.3, ställde vi upp fyra punkter som beskrev de 
brister som kan finnas i svenska organisationer och som BR kan underlätta. Punkterna löd: 


e Organisationer har BR implementerade i systemen men utan struktur. 

e Vetskapen om vilka BR som är implementerade i systemen saknas. 

e Ansvarig för verksamhetsregler, BR, dess implementering, uppdatering med mera saknas. 

e Det är svårt för användarna att spåra eller tyda de regler som används i IS- och IT- 
systemen. 


Efter att vi har genomfört våra undersökningar inom Boverket, två kommuner samt Flygt kan vi 
klarlägga att flera av dessa brister fanns inom alla våra fallorganisationer. Undantaget är 
Boverket som hade en god struktur på många av sina regler. Viss förvaltning av BR inom 
Boverket fungerade relativt bra. I våra undersökningar kan vi inte se varför BRA inte används för 
förvaltning av BR i fallorganisationerna. 


8.1 Svar på forskningsfrågor 


I detta kapitel presenterar vi de svar på forskningsfrågorna som vi fått fram genom hela vårt 
arbete. Vi har kommit fram till våra slutsatser genom att väga samman vår teoretiska och 
empiriska forskning i en diskussion. 


Hur är de automatiserade reglerna implementerade? (1a) 

Även om organisationerna själva är osäkra på detta visar det sig att reglerna genomgående är 
implementerade och spridda i programkod i system och i databaser. Vi antar att det ser ut på 
samma sätt inom Övriga svenska organisationer. 


Hur underhålls de automatiserade reglerna? (1b) 

Hur BR underhålls beror på vilken specifik BR som behöver ändras och hur BR är 
implementerad. Varje gång en regel ska ändras genomförs en diskussion om hur en BR 
förändring ska genomföras. Det finns inga klara metoder för BR-underhåll med undantag för 
systemet Skatan hos Boverket. 


Vem underhåller de automatiserade reglerna? (1c) 

Eftersom flera av systemen inte utvecklas inom de undersökta fallorganisationerna genomförs 
BR-underhåll många gångar av de som levererar systemen. Alla organisationer vi har varit i 
kontakt med har leverantörer som i samverkan med respektive systemansvarig, systemtekniker 
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med flera genomför många regelförändringar. Det system som står ut från de övriga systemen 
inom fallorganisationerna är Skatan hos Boverket. Detta underhålls av anställda vid Boverket 
som bara arbetar med att hålla BR uppdaterade och korrekta. 


Vilka typer av Rule Repositories(RR) har organisationerna? (1d) 

Vi har kommit fram till att det inte används något rent RR i någon av de organisationer som vi 
har undersökt. Boverket använder systemet Skatan som kan liknas vid ett RR. Inom alla fyra 
organisationer finns BR lagrade i databaser men inte heller dessa är helt separerade. 


Är reglerna medvetet implementerade? (1e) 

Boverket har många av sina BR medvetet implementerade och de vet var dessa finns och hur de 
styr men detta gäller långt ifrån alla deras BR. De tre övriga organisationerna har förvisso varit 
medvetna om vilka de aktuella reglerna är och hur dessa BR styr när de skrivit in dem. Men vi 
lägger även in i begreppet ”medvetet” då det finns en struktur och en lätthet att finna och 
uppdatera dessa BR och detta saknas i dessa organisationer liksom i delar av Boverkets BR. 


Är reglerna inbäddade i programkod eller separerade från systemen? (1f) 
BR finns inom samtliga fyra organisationer främst inbäddat i olika former av databaser eller 
programkod, de är alltså inte separerade. 


Hur beskrivs BR i organisationernas terminologi? (1g) 

Samtliga organisationer använder begrepp som verksamhetsregler, affärsregler medan man på 
Flygt även använder processbeskrivning och på Boverket regelprogrammering när de beskriver 
sina BR. 


8.2 Några avslutande reflektioner av vårt arbete 


På förstasidan av denna uppsats finns texten “COMPUTER SAYS NO!”. Detta citat kommer 
ifrån en serie sketcher ur en brittisk TV-serie vid namn Little Britain. I sketcherna yttras denna 
fras av en resebyrå- och en bank-receptionist i syfte att förklara för sina kunder att deras 
önskemål inte är kompatibla med den information som finns i deras dator. Kunderna försöker då 
komma med andra förslag vilka också avslås med en upprepning av samma fras. Kontentan av 
sketcherna är att receptionisten inte har skarpare insikt i varför kundernas önskemål inte kan 
uppfyllas än den att datorn inte godkänner dem. Anledningen till att vi tar upp det i 
sammanhanget är att detta inte ska kunna hända i en organisation som använder BRA. Detta för 
att BR används för att utrycka den verksamhetslogik som styr verksamheten i syfte att synliggöra 
den. Genom att synliggöra detta ger BR organisationens medarbetare en förståelse för varför och 
hur en BR begränsar verksamheten. 


I inledningen av denna uppsats förklarade vi i vilket syfte vi har genomfört våra undersökningar 
och producerat denna uppsats. Med denna uppsats vill vi visa hur BR förvaltas, fungerar och 
används i en verklig miljö i några svenska organisationer. Genom att vi presenterar våra fakta kan 
de organisationer vi undersökt, studenter och ämnesintresserade få en inblick i vad BR är, hur det 
förvaltas och används inom några svenska organisationer. 
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8.3 Förslag till vidare forskning 


Vi har funnit, utan att kunna stärka detta, att kunskapen om BR och BRMS är på väg att slå 
igenom i svenska organisationer. Detta vågar vi påstå efter att ha deltagit i ett seminarium som 
hölls av Fair Isaac (Fair Isaac Seminarium, 2008). Seminariet hölls här i Sverige och Fair Isaac 
som är en av de största leverantörerna av BRMS ville härigenom även marknadsföra sina 
produkter i Sverige. På seminariet deltog framförallt svenska men även norska representanter 
mestadels från privata organisationer. Det vore därför väldigt intressant att undersöka om BR och 
BRMS får större genomslag i Sverige det närmsta året eller åren. 


Om någon typ av mjukvara, så som BRMS, ihärdigt används av flera organisationer inom den 
övriga industriella västvärlden tenderar kunskaper att sprida sig över landsgränserna. För att ta 
beslutet att introducera en ny mjukvara i en organisation behövs kunskaper om mjukvaran och 
hur den fungerar. Något som också kom upp men som vi idag inte själva kan få bekräftat är att 
skatteverket i Sverige har fört diskussioner om att använda ett BRMS. Det skulle därför vara 
väldigt intressant att i framtiden undersöka denna förmodade implementering. 


Vi har ett stort intresse för BR och BRA och tycker det vore intressant att genomföra en mer 
inriktad undersökning. Undersökningen skulle kunna rikta in sig på en svensk eller skandinavisk 
organisation som använder ett BRMS. Eller på en organisation som precis har genomfört eller 
genomför en implementering av ett BRMS. Att införa en ny typ av mjukvara in i en svensk eller 
skandinavisk miljö kanske kräver att exempelvis ett BRMS anpassas för denna miljö. Det vore 
intressant att få svar på dessa frågor. 
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9. Bilagor 
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Bilaga 1: Intervjuguide 
e Innan intervjun 
e Innan intervjuerna påbörjas får intervjusubjektet en muntlig introduktion till 
undersökningen. Vilka vi är, var vi kommer ifrån samt syftet med uppsatsen. 


Vi vill även poängtera att deltagande är frivilligt. 


AA. Är det så att ni önskar att ert namn inte ska finnas med i uppsatsen eller spelar det ingen roll? 


Personliga frågor och Ev. Arbetsfrågor 
A. Namn: 


B. Befattning: 

C. Arbetsuppgifter och ansvarsområde: 

D. Hur länge har ni haft detta jobbet? 

E. Hur länge har ni totalt jobbat inom detta företaget/verksamheten? 

F. Kan du berätta lite kort om vad ni sysslar med här på din avdelning? 


Ämnes frågor 
1:a Hur förvaltar ni regler som styr er verksamhet? 
1:b Har du hört talas om begreppet Business Rules? 
2:a Vill du beskriva vad det betyder? 
2:b Vad använder ni för termer när ni diskuterar regelförvaltning? 
3:a Har ni implementerat regler som används automatiskt i era system? 
3:b Dessa finns kanske i till exempel javakod eller SQL? 
3:c Ar det bara vissa typer av regler som ni har valt att implementera? 
- Vilka är i så fall dessa? 
- Hur gar ni tillväga för att välja vilka regler ni ska implementera? 
4:a Hur har ni implementerat dessa regler? 
4:b Hur underhålls dessa regler? 
4:c Hur gar ni tillväga om en regel ändras? 
4:d Vem eller vilka sköter detta och finns det någon som har det slutliga ansvaret? 


4:e Vilka krav och regler finns för implementering av reglerna i systemen? 
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4:f Är regelförvaltningen en avskildverksamhet med någon eller några ansvariga? 

5:a Har ni något Rule Repository alltså en lagringsenhet speciellt för regler? 

5:b Hur avgränsar ni vilka regler som skall implementeras eller inte? 

6:a Använder ni någon mjukvara (Business Rule Management System) för er regelförvaltning? 
6:b I så fall vilket och hur länge har det varit i bruk? 


7: Skulle du vilja förbättra förvaltningen av era regler på något sätt, finns det något du saknar i 
din organisation vad gäller er regelförvaltning? 


8: Kan vi få se några exempel på hur ni har implementerat regler och hur detta används? 
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Bilaga 2: E-postundersökning 
Hej 


Som avtalat sänder jag härmed våra frågor via e-post. Nedan finner ni lite information om vad det 
är vi söker samt de frågor vi är intresserade av att få svar på. 


De regler vi undersöker benämns ofta som verksamhetsregler, Business Rules, affärsregler m.m. 
Den term vi använder är Business Rules (BR) och det är under detta uttryck vi undersöker dessa 
regler. Vi är ute efter de regler som ni har automatiserat och som finns i era datasystem och alltså 
inte regler som finns i pärmar eller i policys för verksamheten. Anledningen till vår undersökning 
är att BR är ett välkänt begrepp i många länder i västvärlden men att det i svenska organisationer 
verkar vara relativt okänt. Vi vill genom våra frågor finna svar på om detta är fallet, eller om BR 
används men att en annan terminologi används i Sverige. Syftet med vårt arbete är att undersöka 
hur BR förvaltas i en verklig miljö i några svenska organisationer. Vi vill inte undersöka och 
beskriva enskilda regler utan endast se hur de förvaltas i systemen. Materialet kommer att ingå i 
vår magisteruppsats som skrivs på Lunds Universitet. 


Vår uppsats handlar alltså om hur ni förvaltar regler som finns implementerade i era datorsystem. 
En regel kan exempelvis vara att en kund måste vara 18 år gammal, att bara en systemansvarig 
får uppdatera databasen eller att moms måste subtraheras från slutgiltigt pris innan en faktura till 
en företagskund skrivs ut. 


A. Namn: 

B. Befattning: 

C. Arbetsuppgifter och ansvarsområde: 

D. Hur länge har ni haft detta jobbet? 

E. Hur länge har ni totalt jobbat inom detta företaget/verksamheten? 

F. Är det så att ni önskar att ert namn inte ska finnas med i uppsatsen eller spelar det ingen roll? 


1:a Hur förvaltar ni regler som styr er verksamhet? 
1:b Har du hört talas om begreppet Business Rules? 
2:a Vill du beskriva vad det betyder? 
2:b Vad använder ni för termer när ni diskuterar regelförvaltning? 
3:a Har ni implementerat regler som används automatiskt i era system? 
3:b Dessa finns kanske i till exempel javakod eller SQL? 
3:c Ar det bara vissa typer av regler som ni har valt att implementera? 
e Vilka är i så fall dessa? 
e Hur gar ni tillväga för att välja vilka regler ni ska implementera? 
4:a Hur har ni implementerat dessa regler? 
4:b Hur underhålls dessa regler? 
4:c Hur gar ni tillväga om en regel ändras? 
4:d Vem eller vilka sköter detta och finns det någon som har det slutliga ansvaret? 
4:e Vilka krav och regler finns för implementering av reglerna i systemen? 
4:f Är regelförvaltningen en avskild verksamhet med någon eller några ansvariga? 
5:a Har ni något Rule Repository alltså en lagringsenhet speciellt för regler? 
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5:b Hur avgränsar ni vilka regler som skall implementeras eller inte? 

6:a Använder ni någon mjukvara (Business Rule Management System) för er regelförvaltning? 
6:b I så fall vilket och hur länge har det varit i bruk? 

7: Skulle du vilja förbättra förvaltningen av era regler på något sätt, finns det något du saknar i 
din organisation vad gäller er regelförvaltning? 

8: Kan vi få se några exempel på hur ni har implementerat regler och hur detta används? 


Det skulle vara jättebra om ert svar kunde returneras till oss inom 10 dagar. 
Kontakta oss, Carl eller Jon, om ni har några frågor på: 

Carl tel: 0733665271 alternativt pa Mail: carl.bohman2@hermes.ics.lu.se. 
Jon tel: 0735415790 alternativt pa Mail: jon.nordgren@hermes.ics.lu.se. 


Mvh 
Carl Bohman och Jon Nordgren 
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Dear Sir/Madame 


We are writing our master thesis at the Department of Informatics at Lund University. Our topic 
is Business Rules and BRMS, we are hoping for your help in finding some organisation that are 
using your software and that are willing to let us interview them. We would be most grateful if 
you could advice us of an organisation in the south of Sweden. We would also be grateful if you 
would be willing to send us a demo-copy of your software. 


best regards 
Jon Nordgren, Carl Bohman 


+46 (0) 735415790 
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Bilaga 4: Lista över företag som tillverkar mjukvara för BR-förvaltning 


Nedan följer en sammanställning av företag som levererar produkter/mjukvaror för BR- 
förvaltning. Det finns två stycken olika typer av mjukvaror tillgängliga. Så kallade Business 
Rules Engines (BRE) och Business Rules Management System (BRMS). BRE är mjukvaror som 
hjälper en organisation att förvalta och automatisera sina BR. Men BRE kan bara hantera den 
rena exekveringen av en organisations BR, vilka BR ska exekveras och i vilken ordning. Ett för 
en organisation mer heltäckande alternativ att förvalta sina BR är att använda ett BRMS. Ett 
BRMS utvecklas för att organisationens affärsavdelning ska kunna hantera hela sin verksamhet 
med fokus på BR utan hjälp från IT specialister. De leverantörer som på sin hemsida marknadsför 
sin produkt som ett BRMS är märkta i tabellen nedan. Flera av dessa leverantörer har också ett 
BRE i sitt produktsortiment. 


Produktnamn | BRMS | Företag Internetadress 

Blaze Advisor X Fair Isaac http://www. fairisaac.com/fic/en 

BizTalk Microsoft http://www.microsoft.com/ 

Corticon Corticon http://www.corticon.com/ 

Cleverpath Aion Computer http://www.computerassociates.com/ 

Business Rules Associates 

Expert 

Eclipse X Haley http://www.haley.com/ 

eMerge Sapiens http://www.sapiens.com/ 

Idiom decision X Idiom http://www.idiomsoftware.com/ 

suite 

Ilog X Ilog http://www.ilog.com 

InRule InRule http://www.inrule.com/ 

G2 X Gensym http://www.gensym.com/ 

JBoss Rules Red Hat http://www.jboss.com/products/rules/ 

JESS Sandia National | http://herzberg.ca.sandia.gov/jess/index.shtml 
Laboratories 

JRules X Ilog http://www.ilog.com/ 

Logist ESI http://www.esi-knowledge.com/ 

Mandarax fritt projekt http://mandarax.sourceforge.net/ 

Oracle X Oracle http://www.oracle.com/ 

PegaRules Pegasystems http://www.pegasystems.com/ 

QuickRules YASU http://www. yasutech.com/ 
Technologies 

RulesPower RulesPower http://www.rulespower.com/ 

RuleBurst RuleBurst http://www.ruleburst.com/ 

USoft Ness http://www.ness.com/ 

Versata X Versata http://www.versata.com/ 

Visual-Rules X Innovations http://www.visual-rules.com/ 

Xpertrule X XpertRule http://www.xpertrule.com/ 
Software Ltd 
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Bilaga 5: BR manifest 


Business Rules Manifest 


Principerna för verksamhetsreglernas oberoende 


by Business Rules Group 


Artikel 1. Primära krav, inte 
sekundära 

1.1 Regler är en första klassens invånare i 
kravvärlden. 


1.2 Regler är väsentliga för och är en urskiljbar del 
av verksamhets- och teknologimodeller. 


Artikel 2. Separerade från processer 
och inte ingående i dem 

2.1 Regler ar explicita restriktioner pa beteende 
och/eller ger stéd at beteende. 


2.2 Regler är varken processer eller procedurer 
och ingår inte i någondera. 


2.3 Regler verkar tvärs över alla processer och 
procedurer. Det skall finnas ett sammanhängande 
regelverk, som på ett konsistent sätt verkar över 
företagets alla verksamhetsområden. 


Artikel 3. Overlagd kunskap och inte 
nagon biprodukt 

3.1 Regler bygger pa fakta och fakta bygger pa 
begrepp uttryckta med termer. 

3.2 Termer uttrycker verksamhetsbe grepp; fakta 


utgör utsagor om dessa begrepp; regler begränsar 


och förtydligar dessa fakta. 


3.3 Regler måste vara explicita. Ingen regel är 
någonsin underförstådd i ett begrepp eller faktum. 


3.4 Regler är fundamentala för vad man i 
verksamheten vet om sig själv - dvs. för själva 


verksamhetskunskapen. 


3.5 Regler måste vårdas, säkras och hanteras. 


Copyright, 2003. Business Rules Group. 


Version 2.0, November 1, 2003. Edited by Ronald G. Ross. 


Artikel 4. Deklarativa och inte 
procedurella 


4.1 Regler skall uttryckas deklarativt med ett 
naturligt sprak och med ett sprak som ar det som 
normalt används i verksamheten. 


4.2 Om det är något som inte kan formuleras så är 
det inte heller en regel. 


4.3 En uppsättning satser är deklarativt 
formulerad om det inte på något sätt är 
underförstått att satserna skall uppfattas i en 


bestämd ordning. 


4.4 Formuleringar av regler som förutsätter 
konstruktioner med annat än termer och fakta 
innebär att man gör antaganden om hur systemet 
skall inplementeras. 

4.5 Själva regeln är helt åtskild från den del som 
definierar genomdrivandet av den. 

4.6 Regler skall definieras oberoende av ansvar 
för vem, var, när eller hur - när det gäller 
genomdrivandet av regeln. 

4.7 Undantag till regler uttrycks med hjälp av 
andra regler. 


Artikel 5. Välformulerade uttryck 
och inte ad hoc 


5.1 Verksamhetsregler skall uttryckas pa ett 
sådant sätt att de kan valideras av personer i 
verksamheten. 

5.2 Verksamhetsregler skall uttryckas pa ett 
sådant sätt att de kan verifieras att de är inbördes 
konsistenta. 

5.3 Formell logik, som predikatlogik, är 
fundamental för hur regler formuleras i 
verksamhetstermer liksom fér de teknologier som 
implementerar verksamhetsreglerna. 
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Artikel 6. Regelbaserad arkitektur 
och inte någon indirekt 
implementation. 


6.1 En applikation med verksamhetsregler byggs 
med avsikt för att kunna anpassas till en 
kontinuerlig förändring av affärsreglerna. Den 
plattform på vilken applikationen körs skall stödja 
en sådan kontinuerlig förändring. 


6.2 Attexekvera regler direkt - tex med en 
regelhanterare - är en bättre implementations- 
strategi än att skriva om reglerna med ett 


procedurellt språk. 


6.3 I ett system med verksamhetsregler måste det 
alltid framgå hur det kommer fram till olika 
slutsatser respektive leder till olika aktioner. 


6.4 Regler baseras på sanningsvarden. Hur en 
regels sanningsvärde bestäms och aktualiseras är 
dolt för användaren. 


6.5 Relationen mellan händelser och regler är i 


allmänhet manga-till-manga. 


Artikel 7. Reglelstyrda processer, 
inte undantagsstyrd programmering 


7.1 Regler definierar gränsen mellan acceptabel 
och oacceptabel verksamhetsaktivitet. 


7.2 Regler kräver ofta en speciell eller selektiv 
behandling av upptäckta regelbrott. En sådan 
undantagshantering är en aktivitet som vilken 
annan aktivitet som helst. 


7.3 För att möjliggöra maximal konsistens och 
återanvändbarhet skall behandlingen av 
oacceptabel verksamhetsaktivitet separeras från 


behandlingen av sådan som är acceptabel. 


Artikel 8. Det hela är till för 
verksamheten och inte för tekniken 
8.1 Regler handlar om verksamhetens arbetsätt 
och styrning och därför är reglerna motiverade 


utifrån affärsmål och får en utformning beroende 
av faktorer som påverkar verksamheten. 
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3.2 Regler innebär alltid en kostnad. 


3.3 Kostnaden för att genomdriva en regel måste 
alltid balanseras mot affärsrisker och mot de 
affärsmöjligheter som annars kan gå förlorade. 


3.4 ”Fler regler” är inte bättre. Vanligtvis är färre 
"bra regler” bättre. 

8.5 Ett effektivt system kan baseras på en liten 
mängd regler. Ytterligare regler som har en finare 


uppdelning kan sedan successivt läggas till så att 
systemet med tiden blir smartare. 


Artikel 9. Av och för verksamhetens 


folk och inte for IT-mdanniskor. 


9.1 Regler skall komma fran kunnig 
verksamhetspersonal. 


9.2 Verksamhetspersonalen skall ha tillgang till 
verktyg som hjalper dem att formulera, validera 
och hantera regler. 


9.3 Verksamhetspersonalen skall ha tillgång till 
verktyg som hjalper dem att verifiera att 
affarsreglerna ar inbördes konsistenta. 


Artkel 10. Det viktigaste är att 
hantera verksamhetslogik och inte 
hardvaru- eller softvaruplattformar 
10.1 Verksamhetsregler ar vitala 
foretagstillgangar. 


10.2 Pa lang sikt ar regler viktigare for foretaget 
an hardvaru/softvaruplattformar. 


10.3 Verksamhetsregler skall organiseras och 
lagras pa ett sådant sätt att de enkelt kan överföras 
till nya hardvaru- resp. softvaruplattformar. 


10.4 Regler och möjligheter att förändra dem 
effektivt ar fundamentala for att öka företagets 
anpassningsförmåga. 
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Användning av och kunskap om Business Rules i svenska organisationer. 


Bilaga 6: E-postfrågor - Karlskrona kommun 


1:a Hur hanterar ni regler som styr er verksamhet? 

Det finns en mängd regler som styr våra datorsystem. Allt från tjänsteposition, tillhörighet 
(förvaltning) samt tid mm. Dessa system är användare och behörighetssystem. Men det finns 
även system som sätter regler för hur hur mycket disk en användare/förvlatning o.s.v. får använda 
i systemet. Det finns regler som styr vilken typ av information som släpps in i våra system. Som 
sagt alla system har någon typ av inbyggd regelhantering. 


1:b Har du hört talas om begreppet Business Rules? 
Nej! 


2:a Vill du beskriva vad det betyder? 


2:b Vad använder ni för termer när ni diskuterar regelhantering? 
Det variera inom vilket område men det kan vara Quota, access, shaping mm. 


3:a Har ni implementerat regler som används automatiskt i era system? 
Ja 


3:b Dessa finns kanske i till exempel Javakod eller SQL? 
Inte direkt, men visst SQL är uppbyggt kring regler och relationer. 


3:c Är det bara vissa typer av regler som ni har valt att implementera? 
Vilka är i så fall dessa? 
Hur går ni tillväga för att välja vilka regler ni ska implementera? 
Det avgörs från fall till fall och styrs utav funktionen och den kravbild som 
finns. 


4:a Hur har ni implementerat dessa regler? 
Vid inplementationen av ett system 


4:b Hur underhålls dessa regler? 
Funktionen av ett system och dess underhåll och utveckling handhas av en för varje system 


utsedd systemförvaltare. 


4:c Hur gar ni tillväga om en regel ändras? 
I samråd med systemförvaltare och systemtekniker. 


4:d Vem eller vilka sköter detta och finns det någon som har det slutliga ansvaret? 
Se ovan. 


4:e Vilka krav och regler finns för implementering av reglerna i systemen? 
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Förändringar av ett system skall först göras i kommunens testmiljö innan den tas i bruk i 
produktion. 


4:f Är regelhanteringen en avskild verksamhet med någon eller några ansvariga? 
Nej 


5:a Har ni något Rule Repository alltså en lagringsenhet speciellt för regler? 
Nej 


5:b Hur avgränsar ni vilka regler som skall implementeras eller inte? 
Beror på systemets funktion och känslighet. 


6:a Använder ni någon mjukvara (Business Rule Management System) för er 
regelhantering? 

Nej 

6:b I så fall vilket och hur länge har det varit i bruk? 

7: Skulle du vilja förbättra hanteringen av era regler på något sätt, finns det något du 
saknar i din organisation vad gäller regelhantering? 


Det saknas alltid regler som är klara och väl definierade samt utsedda av en stark styrning. 


8: Kan vi få se några exempel på hur ni har implementerat regler och hur detta används? 
Regler för inköp av t.ex skrivare och kopiatorer är idag reglerade till att endast ske vi IT. 
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Bilaga 7: E-postfragor — Flygt, ITT 


1:a Hur hanterar ni regler som styr er verksamhet? 
Vissa regleras pa hög nivå av processansvariga. Regler pa lägre nivå (tex i IT system) kan 
regleras av individuella systemagare eller beställare av system. 


1:b Har du hört talas om begreppet Business Rules? 
Ja 


2:a Vill du beskriva vad det betyder? 
Affarsregler eller om man vill verksamhetsregler. Dessa styr de processer och information som 
finns i foretaget. 


2:b Vad anvander ni for termer nar ni diskuterar regelhantering? 
Lite olika, men affarsregler, business rules, processer osv. 


3:a Har ni implementerat regler som anvands automatiskt i era system? 

Ja, finns i en mängd olika format, Cobol, PL/SQL, T-SQL, ESQL, VB, VB .NET osv. Vi 
använder dock inga automatiserade regel/process motorer motsvarande Biztalk Orchistrator eller 
liknande. 


3:b Dessa finns kanske i till exempel Javakod eller SQL? 
Finns men inget jag har tillgang till just nu. 


3:c Ar det bara vissa typer av regler som ni har valt att implementera? 

- Vilka ar i sa fall dessa? 

- Hur gar ni tillväga för att välja vilka regler ni ska implementera? 

Jag skulle inte vilja säga att det ar specifika typer men givetvis är det bara vissa regler som 
automatiseras och ofta ar det en fraga om de kan automatiseras eller inte. Vissa regler kan inte 
automatiseras och da gors de givetvis manuellt. 


4:a Hur har ni implementerat dessa regler? 
Implementeras i olika system i kod. Dokumenteras ofta i tex processbeskrivningar. 


4:b Hur underhalls dessa regler? 
Underhåll av regler görs per system (om de är automatiserade) och görs inom ramen för 


systemens förvaltning. 


4:c Hur gar ni tillväga om en regel ändras? 
Se 4a 


4:d Vem eller vilka sköter detta och finns det någon som har det slutliga ansvaret? 
Slutgiltiga ansvaret har alltid processansvarig (eller systemägaren). Förvaltaren är den som 


genomför förändringarna i systemen. 


4:e Vilka krav och regler finns för implementering av reglerna i systemen? 
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Att ägaren eller processansvarig har godkänt att de ska ändras. 


4:f Är regelhanteringen en avskildverksamhet med någon eller några ansvariga? 
Nej (finns dock personer som uteslutande arbetar med processförbättringar och där ingår givetvis 
regler för processerna). 


5:a Har ni något Rule Repository alltså en lagringsenhet speciellt för regler? 
Nej. Vi har dock ett Data Dictionary där regler för information finns. 


5:b Hur avgränsar ni vilka regler som skall implementeras eller inte? 
Det görs i fall till fall. 


6:a Använder ni någon mjukvara (Business Rule Management System) för er 
regelhantering? 

Nej 

6:b I så fall vilket och hur länge har det varit i bruk? 

7: Skulle du vilja förbättra hanteringen av era regler på något sätt, finns det något du 
saknar i din organisation vad gäller regelhantering? 


Ett samlat repository för regler vore givetvis önskvärt. 


8: Kan vi få se några exempel på hur ni har implementerat regler och hur detta används? 
Har inget tillgängligt just nu. 
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Bilaga 8: Intervjutranskription - Boverket 

Carl: ehh, vi kan starta med lite förberedande frågor. Kan ni berätta lite kort om vad ni sysslar 
med här. Sammanfatta övergripande vad ni sysslar med så att säga. 

Peter: Själva verksamheten? 


Carl: Ja verksamheten. 


Peter: Ja det kan vi väl göra. Vi är en statlig myndighet, direkt under regeringen, vårt 
ansvarsområden är då så att säga byggande, boende och fysisk planering. 


Carl: Okej. 

Peter: Det är dom tre. Och vi är framförallt, vi har ju lite olika roller, vi är en utredande 
myndighet kan man säga, vi utreder olika frågeställningar inom dessa tre områdena här, åt 
regeringen, som underlag inför beslut och annat. Vi är en föreskrivande myndighet, vi föreskriver 
om regler, alltså förordningar, vi ger ut förordningar med stöd av lagar, plan och bygg lagen och 
andra lagar. Så föreskriver vi och sen även bidrag och utbetalningar när det gäller att betala ut 
statens subventioner till byggandet. 


Carl: Alright. 


Paul: Ja byggandet och även energiförbättringar och andra miljöstimulanser som man har tagit 
fram. Vi har ju gått mycket från byggandet över just till energi och miljö området. 


Carl: Okej, Och ni har kollat igenom mitt papper där med våra frågor. 

Peter: Paul har inte sett det än. Men har fått en utskrift. 

Carl: Jag hade egentligen bara tänkt att köra igenom dom här från början till slut. 

Peter: Men vi kan väl säg, Carl, som en introduktion till Paul då, som inte har varit med i ditt 
resonemang här innan det är ju att du undersöker hur vi hanterar regler[stark betoning på regler], 
verksamhetsregler i våra datorsystem. 


Paul: mm. 


Carl: Ja. [Jag ger muntlig introduktion till vad vår undersökning handlar om och det diskuteras 
lite]. 


Carl: Jag kan börja med den första frågan här. Hur hanterar ni regler som styr 
verksamheten. Det är ju en ganska bred fråga. 


Paul: Det är en bred fråga. 
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Peter: Det var en väldigt bred fråga. 


Peter: Alltså vi har inte liksom generell process för reglerhantering och så va, utan det är klart att 
dom regler vi hanterar i datasystemen alltså dom modeleras och programmeras ju när man bygger 
upp det enskilda systemet så att säga. Vi har inget, nu utvecklar vi ju inte våra system själva, vi 
har ingen egen systemutveckling utan vi beställer våra system. Vi har ju inget generellt verktyg 
för business rules eller så. 


Peter säger till Paul: Men du jobbar ju i en verksamhet där vi har bidragssystem som innehåller är 
väldigt mycket programmerade regler. 


Paul: mm, och det är ju egentliga att, vi ska iochförsäg hålla oss till reglerna i systemen, men 
allting grundar ju säg på det som Peter var inne på att regeringen ger ut lagar och förordningar 
och i dom finns det bestämmelser som vi då har att följa. Och sedan kan dom bestämmelserna 
vara mer eller mindre vaga. Och det är därför vi har den här föreskriftsrätten så att vi förtydligar 
egentligen de bestämmelser vi har fått ovanifrån att hantera här. Och det är då det vi gör i 
föreskrifterna och hela det här materialet ligger till grund för de regler som sedan implementerar i 
systemen. Och när gäller just det, till exempel det system som vi har för att administrera statliga 
stimulanser. Där har vi byggt upp ett regelverk i själva systemet där vi då själva kan lägga in dom 
olika bestämmelserna, när det kommer ett nytt stöd till exempel så att uppbyggnad av en hel del 
olika tabeller i det regelverket. Och det finns väl ett åttiotal olika tabeller som man då 
implementerar dom olika bestämmelserna i och sedan så är det de som styr handläggningen. Du 
får in en ansökan till myndigheten, kanske snarare ska säga, ja myndigheten därför att, framförallt 
så är det länsstyrelserna som arbetar i dom här olika systemen och handlägger ansökningar om 
olika typer av bidrag. Och då kommer vi också in på det här med behörighetsbiten som du 
nämnde. 


Peter: Och vi har ett särskilt namn på den regelmodulen va. 
Paul: Ja det har vi, Skatan heter den. 
Carl: Vad är den implementerad i, är det java eller en databas. 


Paul: Nej det är en microsoftdatabas som, ja egentligen ska man väl säga att det är en oracle 
databas som ligger till grunden. Men för drygt två år sedan så började vi går över till mer och mer 
microsoft och använde microsofts verktyg, men fortfarande så finns den här oracledatabasen kvar 
som en grund. Det är det nästa steg att vi ska byta även den och det beror framförallt på att vi 
behöver mycket mer spetskompetens från de konsulter som vi anlitar när det gäller oracle än 
microsoftprodukten. Och då har vi olika fågelnamn på våra system. Så det handläggarstödda 
systemet det heter bofink, vi sa lite övermodigt att det var boverkets final koncept när vi 
bestämde oss för att utveckla systemet. Så vi gick från stordatorsystem till ett system som vi hade 
i huset istället. Och då är det att man inte sitter lika fullt i knäna på konsulterna utan vi har 
möjlighet att styra själva. 


Carl: Alright. 
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Paul: Sen bildades det en IT-enhet nu, i början av det här året, och där tittar vi över att vi själva 
ska kunna göra en del av det arbetet som vi har utkontrakterat tidigare. Så att viss utveckling ska 
vi kunna göra själva här i huset. Och det har vi inlett nu, en liten översyn över vad vi ska kunna 
göra och successivt ta över arbetsuppgifter som har utförts av konsulter tidigare. 

Sen som ett delsystem i bofinksystemet så har vi då skatan. Och det är helt enkelt där vi bygger 
upp dom olika reglerna som gäller för systemen. Sen har vi ju även andra system, och då kommer 
vi just över till det här med behörigheter att det här är en beslutsgång och du får då ansöka om en 
behörighet hos boverket och vi kan då bevilja den. Och sen har vi då ett behörighetssystem som 
heter höken, som du hör det är bara fåglar, där vi då lägger upp dom behörigheter och egentligen 
är behörigheterna uppbyggda på olika roller, att du får göra olika mycket i systemen, tillgång till 
olika mycket av uppgifter som finns samlade i systemen. 


Carl. Alright. 
Peter: Så man kan säga att det är ett form av reglerverk. 


Paul: Sen har vi även energideklaration, kanske hört talas om att man ska energideklarera alla 
sveriges byggnader, ivartfall dom som är uppvärmda. Så det är ungefär 3.4 miljoner byggnader 
som ska energideklareras. Och där är vi då registermyndighet så att vi har byggt upp ett register 
där vi registrerar då dom besiktningarna och innehållet i besiktningarna. Sen producerar det 
systemet något man kallar, lappen i trappan, som talar om hur energieffektivt huset är i 
förhållande till då ett normvärde baserat på likvärdiga fastigheter. Och även där har du ett 
behörighetssystem där certifierade organ med besiktningsmän då kan begära att dom ska få 
behörighet i systemet. Men då begär dom det på en högre nivå, så att även det tekniska ansvaret 
hos det här certifierade företaget som får en behörighet, och sen kan har i sin tur lägga upp andra 
besiktningsmän så att dom har behörighet till systemet. 


Carl: Tolkar jag det rätt att, ni pratade om databasen, att ni skriver upp alla externa reglerna så 
har ni i databasen så att ni ska kunna hitta dom lätt. Men interna regler har kanske inte så mycket 
koll på? 


Paul: Nej[långdraget] man kan säga att det finns inte så mycket interna regler i den systemet 
skatan, om vi går till stimulanserna. Däremot, ja på sätt och vis, vi hade ju dom här övergripande 
bestämmelserna som gäller för stimulanserna. Men sen har vi också att uppdrag att vi ska följa 
upp effekterna av stimulanserna och då måste vi göra en utvärdering och se om man har uppfyllt 
det mål som man har. Och i och med att vi har föreskriftsrätt så kan vi föreskriva att för att du ska 
kunna behandla ett ärende när du ansöker om bidrag så måste du ange dom och dom här och dom 
här uppgifterna. Och då är det ju egentligen våra egna regler som vi har fått lov att stifta på grund 
av att man har fått den här föreskriftsrätten, att vi har rätt till att skriva våra egna regler om dom 
olika stödformerna. Och sedan så har du ju också, egna regler, iochmed att du har en validering 
på de uppgifter som man har angett när man söker bidraget, så att du kan inte lägga in felaktiga 
eller orimliga värden som sen ska användas för beräkningen av stimulansen. 


Carl: Nej, så det finns lite begränsningar där. 


Paul: Det finns begränsningsregler där. 
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Carl: Alright, det tyckte jag var ett bra svar på min första fråga. Vi går vidare till nästa 
fråga. Vi håller på att jobba med ett begrepp egentligen som vi använder, vi använder 
begreppet business rules. Känner ni igen det? 


Peter: Som begrepp, ja gör vi. 
Carl: Kan du beskriva vad det betyder? 


Peter: Det betyder verksamhetsregler eller affärslogik, för mig betyder de det. Regler som styr 
verksamheten som du själv var inne på. För att få göra en viss grej så ska du vara legitimerad 
eller du ska ha uppnått en viss ålder. 


Carl: Ja affärslogik var ett ord som jag också känner igen. 
Carl: Så vad använder ni för termer när ni diskuterar regler? 


Paul: Jag skulle vilja påstå, inom min verksamhetsområde så är det väl inget vi direkt diskuterar, 
vad vi ska använda för termer utan det är snarare något som ligger som en naturlig del i själva 
arbetsprocessen. Däremot kan så man väl säga att, inte bara just när det gäller regler men 
överhuvudtaget, så har vi haft ömsesidiga utbildningar mellan boverkets personal och våra 
konsulters personal. För det märkte vi, när vi började bygga dom här systemen, att verksamheten 
använde en helt annan terminologi än vad då konsultsidan inom IT gör. Så där kunde det bli en 
språkbristning eftersom att man hade olika begrepp eller olika betydelser i begreppen. Men man 
kan väl säga att det som vanligast används det är väl just verksamhetsregler och då är ju de det 
som styr vår verksamhet överhuvudtaget. Men sedan när vi går ner på de bestämmelser som 
följer av förordningar, lagar och så vidare då brukar vi tala om bestämmelser. Som då ligger till 
grund för att du ska kunna få ett stöd, vad är det som du måste uppfylla för kriterier för stödet. 


Peter: Men själva begreppet regler är ju ett känt begrepp i vår verksamhet när vi pratar om regler 
så att säga. Lagar och regler och så. Vi jobbar ju mycket med lagtillämpning, speciellt i den 


bidragsgivande delen. 


Paul: Ja och även i plan och bygglagstiftningen. Man kan väl säg att vi är ju den myndighet som 
talar om hur du ska bygga ett hus från minsta lilla spik och uppåt. 


Carl: Ja jag såg alla blanketterna där nere. 
Paul: Ja precis. 


Peter: Vi skriver ju landets byggregler vettu, så alla som bygger ett hus går och läser så här ska 
det va, så det här måste ni ta hänsyn till. 


Carl: Och då har vi redan gått igenom 3a, Ja ni implementerar regler automatiskt, det är klart att 
ni gör. 


Carl: Du kanske kan förtydliga den där databasen, jag kanske också kan få komma in och kolla 
på den? 
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Paul: Ja Marie och Roger kan hjälpa dig. 


Paul: Jag tror att Marie och Roger kan berätta mer om det fungerar. Dom är mer inne på den 
tekniska biten. 


Carl: Är det bara vissa typer av regler som ni har valt att implementera? Vilka är i så fall 
dessa? Hur går ni tillväga för att välja vilka regler som ska implementeras? 


Paul: Egentligen kan man väl säga att de bestämmelser som styr vår verksamhet, och även styr de 
stimulanser och sådant. De är ingenting som vi kan välja om vi vill implementera eller inte. Utan 
samtliga regler måste implementeras för att du ska kunna bevilja ett stöd. Men sedan så är det då 
kanske underregler, om vi talar om validering av vad som ska kunna matas in i systemet eller 
inte. Där är det vi själva som bestämmer på vilken nivå som man lägger sig. Vi håller ju på med 
bland annat e-tjänster nu så att du ska kunna ansöka om ett stod elektroniskt och vara helt utan 
pappershantering. Och där kommer ju mycket av det här med valideringen direkt i 
ansökningsformuläret och i övriga formulär in. Du får inte ha för hög grad av validering heller, 
alltså att du styr den sökande i alltför hård grad, därför då blir det att han ger upp kanske när han 
har gått halva formuläret. Att han hela tiden blir slagen på fingrarna att så får du inte skriva, så får 
du inte skriva. Utan man måste hitta en lämplig nivå för att man ska använda sig av e-tjänsten 
istället för att man ska ge upp och skriva ut ansökningsformuläret i pappersform och sen fylla i 
den för hand. Och det är ju just där som vi kan styra själva hur hårt vi vill att dom här reglerna 
ska vara styrande. 


Carl: Okej är det den databasen ni använder då? 


Paul: Ja när det gäller stimulanserna. Men sen är det ju samma sak med energideklarationerna. 
Där finns det ju olika områden som du måste besiktiga huset, olika värden som du måste ta fram 
och leverera in. Och även där så är då besiktningsmannen styrd helt så att han måste fylla i det för 
att han ska kunna lämna in besiktningshandlingen och få ut den här lappen i trappen, alltså 
resultatet av besiktningen. Och där är det ju också vi som bestämmer hur hårt man ska tycka på 
den för att få så rättvisa resultat som möjligt. Så att vi måste följa de regler som våra huvudmän 
ger oss, bestämmelser, men sen så kan vi då ha underregler, hur hårt det styrs i systemet för att du 
ska få igenom ett ärende. 


Carl: Det är mot personerna som ska göra det? Alltså personerna som ska komma och ansöka om 
någonting? 


Paul: Ja både dom som ansöker och de handläggare som handlägger en ansökan. För att även där 
är det, som jag sa vi håller på med uppföljning och många gånger kan ju en del av de här 
uppföljningsvärdena som man ska mata in inte ha någon betydelse för beräkningen av ett bidrag, 
om du ska få stödet eller inte. Men vi behöver dom för att kunna göra uppföljningen och då styr 
vi handläggarna så att det är obligatoriska uppgifter han ska fylla i dom olika fälten. Och där ser 
man ju också, att är det för mycket sådana uppgifter så hoppar handläggarn gärna över det, och då 
har vi ett bristfälligt underlag för det arbetet vi vill göra, med uppföljning av effekter och 
ändamål. 
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Peter: Ja och sen är det ju mycket av vår verksamhet som inte är implementerad i systemen. 
Paul: Nej 


Peter: Som också innehåller en massa regler, att vi till exempel, vi är en utredande myndighet, vi 
utreder olika frågor, vi svarar på överklaganden och omprövar beslut och så. Och där är det ju 
mera, alltså själva den verksamheten är det ju mera stödsystem som kommer in. Så att vi skriver i 
word och officepaketens system och så. Och då finns det ju en hel del regler som du måste hålla i 
huvudet, när måste ett överklagande komma in och när ska jag svar och vad är det gränser och så, 
det kan ju också styras i ärendehanteringssystemen med stöd och så men det har vi ju inte 
alltigenom så va. Men det är klart sen i dom kontorsadministrativa systemen så finns det ju också 
regler. Vem har åtkomst till vilka mappar och så va. Och det är ju en form av behörighetsregler 
som finns där med. 


Carl: Hur underhåller ni dessa regler, nu har ni pratat om många olika regler men om vi 
tar en regel i den här databasen skulle ändras, hur går ni tillväga om den ändras? 


Peter: I vilket tillfälle ändras den. 


Paul: Ja där är vi ju tillbaka igen till just att man kanske upptäcker att när vi gör utvärdering av ett 
stöd att vi inte riktigt fyllt den mål som är givet för det stödet, den har fått de effekter som den 
skulle ha. Och då blir det att regeringen går in och ändrar i en sådan förordning med 
bestämmelser för reglerna. Och då är vi med i en dialog med det departement som är ansvarigt 
för stimulansen hur den ändringen bäst ska göras. Och då blir det att vi dels tittar då på 
pappersnivån hur bestämmelsen ska utformas. Men sen tittar vi, parallellt med det, även på våra 
olika system, att hur hanterar systemet en sådan regeländring. Så att man är med egentligen från 
scratch och följer upp och ser att, för att man kan ju många gånger kanske göra en regeländring, 
eller ha en bestämmelse som inte går att omsätta rent datatekniskt så att systemet ska kunna styra. 
Utan där är då IT-sidan med för framskapandet av regeln och sedan så är det ju också så att det är 
väldigt tidsbestämt när dom här reglerna ska börja tillämpas. Man säger att regeländringen ska 
träda i kraft den första juli till exempel. Och då måste vi ha tagit och uppdaterat systemet också så 
att de hanterar den regeländringen. 


Peter: Då går vi in i skatan. 


Paul: Så att då går vi in i skatan och så ändrar vi den och den tabellen. Och antingen kompletterar 
den eller ändrar för det kan ju tillkomma nya regler inom samma område. 


Carl: Hur många regler kan det finnas i den här skatan? 

Paul: [Pustar] 

Peter: Hur många som helst. 

Paul: Ja egentligen men vi tittade ju på det när vi höll på med plattformsbytet. Ja, i runda tal så 


ligger det någonstans mellan 175 och 200 000 regler. Av olika dignitet naturligtvis. 


Carl: jaja. Då måste ni ändå först hitta den regel som måste ändras. 
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Paul: Ja visst. 
Carl: Hur gör ni då, när ni sitter och söker? 


Paul: Vi har sökverktyg i det här skatansystemet. Som vi då kan göra sökningar och många 
gånger är det ju också att man skapar formler för olika beräkningar, och då har vi ju 
formelhjälpreda så att säga som då hjälper oss att skriva den här formeln på rätt sätt, att vi får dit 
dom dubbla parenteserna där och sen att det verkligen finns samma antal i slutet och så vidare. 
Det är rätt komplicerade formler så att göra det på fri hand är inte världens enklaste. Men du har, 
som sagt va, sökmotor och formelhjälp. Det ser du när du går in och tittar i skatan, så har vi olika 
rullgardiner där du har dom olika tabellerna. Och sedan så har du också hjälp därför att, en regel 
slår inte igenom bara i 1 tabell utan det kan vara 4,5,6,7 olika tabeller. Och sedan för att den ska 
få genomslag så är det inte att man kan välja vilken tabell som helst och börja göra ändringen 
utan man måste göra det i viss ordning för att den ska få verkan i systemet. Och även där har du 
hjälp som berättar för dig hur. 


Carl: Är det för att den anropar andra regler? 


Paul: Ja precis så du har en manual som hjälper dig så att du bygger upp den på rätt sätt. Och då 
menar jag inte en manual som man har till telefonen eller liknande utan den är mer en hjälpreda 
som talar om för dig hur du ska göra när du börjar göra fel. 


Paul: Säg att jag ska börja göra en reglerförändring i systemet och jag har tre olika tabeller, och 
då måste jag börja med tabell två och lägga in den här första ändringen för att jag sedan ska 
kunna göra det i tabell tre. Och sen, tidigare, så hade vi då inte något som hjälpte oss om vi 
gjorde något fel, att vi började i tabell tre istället för tvåan, och då blev det kaputt av det hela. 
Och det är då därför vi utvecklade verktyg som hjälper oss att göra rätt så att säga. 


Peter: I vilken ordning. 
Paul: Ja i vilken ordning och på vilket sätt du ska göra ändringen. 


Paul: Skulle inte ett bra exempel vara vår säkerhetspolicy. För den styr ju vad man får lov att göra 
i våra verksamhetssystem. Och om man då göra en uppdatering och ändring där så är det så att 
man hela tiden har ett underliggande dokument som talar om att så här är bestämmelserna, så här 
är reglerna inom boverket. Och gör man då en ändring, i dokumenten, så är egentligen den 
ändringen samtidigt en beställning, att man samtidigt måste göra samma förändring i det 
verksamhetssystem som vi har, det system som vi har överhuvudtaget. 


Carl: Har ni dom bestämmelserna samlade i något dokument? 
Peter: Nej inte samlade i något dokument, vi har en så differentierad verksamhet, olika 
systemstöd i olika delar av verksamheten. Så vi har inte bofinks regelverk samlade, till exempel 


där vi har lönesystemets regelverk. Utan varje system har ju sitt regelverk så att säga. Så att vi har 
inte den samlade bilden, det är inte ändamålsenligt. 
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Carl: Okej, Är regelhanteringen en avskild verksamhet med någon eller några ansvariga? 


Peter: Alltså regelhantering kopplat till systemen är inte alla inblandade i utan det är ju dom som 
är ansvariga mot det, respektive, system, systemägaren, systemägarrepresentanten. Och 
naturligtvis leverantören som tillhandahåller systemet. Det gäller för de regler som är 
implementerade i systemet. 


Carl: Ni har avgränsat systemet till att göra olika saker så har ni då ansvariga för varje system. 
Peter, Paul: Ja så är det. 


Carl: Har ni Rule repository, en speciell lagringsenhet speciellt för regler, kan man säga att 
den här databasen(skatan) kan vara en sådan? 


Peter, Paul: Ja. 
Carl: Hur går ni tillväga för att avgränsa vilka regler som ni ska implementera? 


Paul: Egentligen så är det så att vi får våra regler från många olika håll. Och dels har vi ju 
egentligen övergripande dokument för hela verksamheten, det är regleringsbrevet, där då 
regeringen talar om för oss vad det är för verksamhetsområden vi ska arbeta med och vad vi ska 
utföra. Sen utmynnar från regleringsbrevet en mängd andra olika dokument som vi då kommer 
ner på dom olika verksamhetsområdena. Och det kan då dels vara lagar och förordningar, det kan 
vara att vi tar fram projektplaner. Och projektplanerna kan då innehålla regler. Och sen så får vi 
då se om vissa regler ska implementeras i system, till exempel stimulanserna(dom där 
bestämmelserna i skatan) är ett bra exempel. Medan andra regler finns egentligen bara i 
pappersform som vi har att rätta oss efter när vi utför våra olika uppdrag. Och det ju vara just det 
här att vi ska göra en översyn av plan och bygglagen och de föreskrifter vi har till den, egentligen 
ett direkt uppdrag som vi har. Det är då som du många gånger skriver en projektplan, där man där 
i projektplanen tar fram regler men då är det ju pappersregler som inte är implementerade i något 
system. Så man kan säga att det är en kombination av flera saker. 


Carl: Har ni hört talas om något som kallas ett business rules management system? 
Paul: Ja, mmm, 
Carl: Är det något som ni har funderat på att ni kanske kan använda? 


Paul: Nej inte direkt(det har de inte tänkt på att använda). Möjligen så kan vi ju säga att det här 
beställningsförfarandet vi har internet, externt, och som vi även ska bygga ut, där har vi en egen 
regel, delvis, och det är att man ska kunna följa ett uppdrag som man lämnar externt till en 
konsult, från a till ö så att om vi gör en revision eller om någon annan gör en revision mot oss så 
ska det finnas svart på vitt vad som har hänt från det, till exempel, när man började utföra en 
förändring i systemet med hjälp av externa konsulter. Och där har vi ett beställningssystem som 
heter prime portal och det är också regelstyrt, att det är vissa personer som har rätt att göra en 
beställning, vad har man behörighet, rätt att göra i själva beställningen. Och då har vi det 
uppdelat här, du har verksamheten som säger att denhär ändringen ska göras i det systemet, sedan 
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så har du IT enheten som har det tekniska ansvaret att ändringen passar in i den tagna plattformen 
och policyn för plattformen som boverket har. Så där gör man då en tekniska beställning eller 
kravspecifikation gentemot leverantören, sen är det då olika led så det är hela tiden att man styr in 
vilka som får göra vad och att du följer det beställningsförfarande som vi har fastställt att du 
måste gå efter. 


Carl: Vad är det i detta som gör att ni inte tycker att ett BRMS inte passar in? (feltolkning 
av mig) 


Paul: Det är inget som säger att det inte passar in. Det är bara det att vi inte har funderat på det. 


Peter: Det är klart att det kan mycket väl passa in. Det är bara det att vi inte har orkat ta den totala 
grejen. 


Paul: Det är inget ställningstagande vi har tagit att vi inte ska ha det eller att vi ska ha det utan vi 
har väl överhuvudtaget kanske inte tänkt på det. 


Carl: nej nej. Skulle ni vilja förbättra hanteringen av era regler på något sätt, finns det 
något du saknar i din organisation vad gäller regelhantering? 


Paul: Skulle vilja säga att det funkar ganska bra. Möjligen kan man väl säga att vi skulle behöva 
något övergripande som har bättre koll på, kanske inte just på hur vi implementerar och använder 
regler och bestämmelser i våra olika IT system. Men däremot som har ett grepp på vad är det som 
organisationen har för system överhuvudtaget och hur gör man när man implementerar reglerna. 
Och där finns det brister i organisationen att dom inte implementeras vid rätt tillfälle, och så 
vidare, och där har vi tagit ett steg i sätt riktning iochmed att vi har IT enheten som då har grepp 
över att samtliga system vi har här och att det passar in i den plattform som vi har bestämt. För att 
annars finns det ju en risk att det spretar åt alla håll plus att man håller på med samma saker på 
mer än ett ställe. 


Peter: Det kan vara så att en sådant management system för reglerna kan vara rent av begåvat. 
Men vi har inte orkat ta det. 


Paul: Ja 


Carl: Vet ni om det finns någon annanstans (BRMS)? 
Carl: någon annan myndighet som pratar om det? 


Peter: Ja, Försäkringskassan pratar om det, dom har ju så mycket bidrag och så många liknande 
regler som återkommer i olika bidrag och så. Så dom har ju en helt, alltså hela deras verksamhet 
är ju en bidragsorganisation. Med en hemskt massa system som hanterar olika saker så dom 
skulle nog vara väldigt förtjänta av en regelhanterings, reglerstyrningssystem. 


Paul: mm, mm 
Carl: Tackar för samtalet. Något att tillägga? 


Det var okej att höra av oss om vi vill fråga några andra frågor. 
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Bilaga 9: Screenshots - Boverket 


BOFR0014 —Stodforn 


Stödformskonto 298 rader 


|od | stod® i . Ä | | Kostnadsstall 
ändamål typ | > le 


oje|ojo|o|ojojojojo|ojojojojojojoj ojojo 


= 


ae TS) a (SE (ge FRV GEN 


540701 
540702 
540702 
540702 
540702 
540702 
540702 
540702 
540702 i 


Spara och stäng Avbryt 


8/8/8/8/8/8/8/8/8/8/8/8/8/3/2/2/2/3/3 2 E 


‘PPPPPPPT PLL RRR SS ee yess 


a|z|2|2|3|2|0|0|>|z|o|z|0|z 


I 
| 
| 
| 
| 
| 
I 
| 
| 
| 


98 


Användning av och kunskap om Business Rules i svenska organisationer. 


Ärende 


Ärende 
Län Stödtyp Ärendenummer 


Fastighetsbeteckning 


Beshtstyp | Beslutsdatum | Bekräftare 


Ansökningar — 
| Ansékningstyp Diarienr Inkommet “| Sökande > Personnrföranr Antal Föredrag 


Inget data. 


Stödändamål 


[TG Srunduppoiter | Sökande || £3} Eastigheter (= Uppmatningsdata | Kontrol | % Beslut | 
Datum 


Stôdändamål " 


Inget data. 


Skattekategori 


Hustyp Upplåtelseform | Produktionsform 
Valifaktivera BUY 


Statistikuppgifter 


Agarklass * 
Inget data 


Spara och Stang 
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Ärende 

Ärende 

Län — Stödtyp Arendenummer  Fastighetsbeteckning ‘var finns ärendet 
Ansökningar 

> Ansökningstyp Diarienr Inkommet “Sökande Personnr/Orgnr Antal | Föredrag _Beslutstyp Beslutsdatum Bekräftare 


Í Sök ärende 


Sökbegrepp 
Ärendenummer 


SekeljPersonforg nr 
Fastighets-trakt/block/enhet 


Fl] Grunduppgifter 


Stédandamal * 


Huvudakt 


Stödkategori 


Kommun 


Län / Stödtyp Ärendenum... / 


Inget data. 
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Om SKATAN 


- Applikation 


ns 


SKATAN - Regelverket BOFROOO9 Formel (FORMEL) 
5.2.10 


Formelkod 


Copyright © 1997-2008 Boverket DIRELBIDRAG Formeltest 
Alla rättigheter förbehållna 


Formelbeskrivning © 
Krediteringsstéd far konvertering från direktverkande elvärme DIREL 2005 12 28 KES, 
ANH 


Användare: lee 
Terminal: MaRa 
Session: =z Formel” 


DIRELUNDERLAG~070: AVRUNDA(((DIRELANDEL / 100" (DIRELUNDERLAG) >(30000"ANTA 
LLGHARB)2(30000"ANTALLGHARB+SOLSCHABLON-KONVERAVDRAG):DIRELANDEL/ 100 
”(DIRELUNDERLAG)+SOLSCHABLON-KONVERAWDRAG) <0)?0:DIRELANDEL/100"(DIREL 
UNDERLAG) >(30000*4NTALLGHARB)?(30000*ANTALLGHARB+SOLSCHABLON-KONVER, 
AVDRAG):DIRELANDEL/100"(DIRELUNDERLAG)+SOLSCHABLON-KONVERAVDR AG, 0) 


Spara Spara och stäng Avbryt 
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SKATAN - Regelverket 
5.2.10 


Copyright © 1997-2008 Boverket 
Alla rättigheter förbehållna 


Användare: RR RE 


Terminal: esse, 
Session: = 


porro... |E |0 [x 


BOFR0027 


Variabel 


1314 rader 


Variabel (VA 
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+ 


| Pres, ord * 


HJÄLPVARIABEL AATERAMOSRBX, UTBBERÄK 


BERÄKNAT BIDRAG I ACK 


ärendet har fått medgivande för påbörjande 


AMORTERINGSBELOPP, (50 ÅR) 


AMORTERINGSBELOPP, (40 ÅR) 


AMORTERINGSBELOPP, (30 ÅR) 


AMORTERINGSBELOPP 


AMORTERINGSBELOPP FÖRKÖPSFÖRVÄRV 


Summa amorteringar tom innevar, Beräkn.Period 


|Bidragsandel, % - 


fo för lgh <= 70 m2 BOA (även stimul) - 


anges för ungdomsbostäder, "2" för studentbost 


0 Antal annan lyftanordning 


Även ansökan om bostadslån har inlämnats i ärendet 


UTBETANTAL BERÄKNINGSDAGAR 


0 Hjälpvariabel för beräkning av aktFullsbsand 


Hjälpformel, delkonvertering 


al 
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SKATAN - Rege lverket 
Om SKATAN 


nd 


SKATAN - Regelverket 
5.2.10 


Copyright © 1997-2008 Boverket 
Alla rättigheter förbehållna 


Användare: 


Uppmätningsdata 988 rader 


Uppmätningskod 


, 


| Pres, ord, 


+ 


Klartext 


Ange "1" för ungdomsbost, "2" för student! 


Beskrivning 


Ange "1" för ungdomsbost, "2" för studentbost (0) 


Ange antal fastigheter vid fler än 1 


Ange antal fastigheter vid fler än 1 


Aterkravsbelopp investeringsbidrag, ACK. 


Aterkravsbelopp investeringsbidrag, ACK. 


Aterkravsbelopp inomhusklimat 


Bterkraysbelopp inomhusklimat 


Bterkravsbelopp extra statligt stöd 


| Återkravsbelopp extra statligt stöd 


IATERBELFIM 


Återkravsbelopp inomhusmiljan 


Återkravsbelopp inomhusmiljön 


TATERBELOMBA 
TATERBELRADB: 


Aterkravsbelopp ombyggnadsbidrag aldrebo... 


Aterkraysbelopp ombyggnadsbidrag äldreboende 


Aterkravsbelopp radonbidrag 


Aterkravsbelopp radonbidrag 


TATERBELSIN 


Aterkravsbelopp investeringsbidrag, SIN 


Aterkravsbelopp investeringsbidrag, SIN 


IBELOPP 


Sökt stöd, kr 


Sökt stöd, kr 


IBEVEFBBIDRAG 


Ange med"1"om extra statligt stöd beviljats ... 


Ange med"1"om extra statligt stöd beviljats (ess). 


IBIDRAGBELOPP 


Sökt bidrag, kr (0) 


Sökt bidrag, kr (0) 


IBLANDAT 


Både normal- o studbost i proj, 1= ja, 2=ne... 


Både normal- o studbost i proj, 1= ja, 2=nej, (0) 


IBYGGAR 


Ange nybyggnadsår (0) 


Ange nybyggnadsår (0) 


TEKOUMDERLAG 


Godkänd kostn. ekologiska åtg vid bostadby... 


Godkänd kostn. ekologiska åtg vid bostadbyggande 


ss 
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Bilaga 10: Intervjutranskription - Emmaboda kommun 


Hur förvaltar ni regler i organisationen? 


Henrik: Hur vi hanterar regler som styr vår verkasamhet? det vi har automatiserat idag är på 
skolsidan när det gäller användarna. Så att de användare som kommer till som är, som kommer 
till och som bildning (bildningskontoret) skriver in I sitt system skapas och tas bort med 
automatik i användarregistret eller om man ska säga AD:t då, så det styrs av regler. När det gäller 
administrativa-nätet och har vi regler beroende på vilka grupper de tillhör, men vi har inget med 
automatik där. Så jag får sitta och skriva in vilka grupper de tillhör och vilka rättigheter . 


Så på bildningskontoret ändrar de sina regler själva eller? 


Henrik: Ahh de sätter tillexempel in att denna eleven har flyttat från Johansfors klass 4 till 
Emmaboda för att han inte trivs eller nått. Då har de regler i sitt system och då kör man en 
synkning och uppdattering då helt plötsligt tillhör han de andra grupperna. Alltså han blir 
tilldelad nya rättigheter per automatik. Denna möjligheten har vi inte idag när det gäller det 
administrativanätet. Men vi kommer att ha det när vi byter det personaladministrativasystemet för 
då kommer vi att kunna plocka ut uppgifter på ett bättre sätt. 


Men vad har ni för system? 


Henrik: I dag ligger det på tienators stordatasystem, det är svårt att plocka ut uppgifter där och 
inte bara det utan det kostar pengar också. Men nu ska vi starta ett samarbete med Borgholm och 
ha ett gemensamt PA-system. Då kan vi be någon stakars företagare göra regler så att man per 
automatik hamnar på rätt ställe. Men regler här får vi i dagsläget ordna manuellt men det kommer 
att komma så att det blir automatiskt vilka rättigheter, grupper och så man ska ha. Och de är 
likadant med de andra systemen till exempel ekonomi där det sitter en person och tilldelar 
rättigheter. Eftersom vi är en liten kommun så är det ju inte så krångligt att göra det och som på 
ekonomikontoret sitter fyra personer då är det ju inga problem att fixa det manuellt om det istället 
hade varit 100 personer hade det ju varit vettigt att automatisera dessa regler. 


Ja det blir ju värre och lättare att blanda ihop om man är fler. 


Henrik: Jo tack vare att vi är så små kan vi enkelt göra det manuellt utom i skolan då där är det ju 
3500 elever jag menar sitta och knacka det varenda sommarlov och dessutom när man är klar så 
kommer de och säger att de här har flyttat! Ah grattis när man suttit och skrivit in dom 
(SKRATTTTT). Så där har vi funnit det nödvändigt att sköta det med automatik. Fördelen är ju 
då att skulle de säga att den här eleven kan inte komma åt denna mappen så är det de själva som 
skrivit in fel i sitt system eftersom det är synkat då. Men jag kan ju ändå alltid kolla vad de 
skrivit. 


Okej och du styrväl de som får lägga in och ändra i systemet? 
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Henrik: Jo jag styr ju vad administratörerna där ute får göra. Jag vet inte om detta var svaret men 
det var väldigt vad mycket pratat det blev. Men det är så att reglerna styrs manuellt på den 
administrativa sidan jag menar allt utom skolan som har regler som styr per automatik. 


Hur är det med ekonomisidan och faktureringar och liknande? 
Henrik: Allt styrs manuellt både med faktureringar och rättigheter och de styr de ju skälva då. 


Har du hört talas om BR? 
Henrik: Nej! 


Vilka termer använder ni när det gäller sådant som BR? 


Henrik: Vi säger nog regler och när det är beslut är det mer sådant som är bestämt över oss, som 
tillexempel de styrandes visioner som vi ska följa. Som att alla ska trivas bättre i vår kommun är 
deras vision och då får vi följa den genom att göra saker som att hjälper för att uppnå detta. Men 
regler kan vi skapa själva. 


Hur lägger ni regler eller kodar har ni något kodat i Java eller någon mjukvara? 


Henrik: När det gäller skolan så är det ett litet program som ligger ut hos ett externt företag som 
gjort det. Som hämtar från en databas och lägger in det i AD:t i det här fallet. 


Kan du själv ändra några regler i det programet? 


Henrik: Nej då måste jag ta kontakt med företaget, det har fungerat så bra med att vi har sagt 
vilka regler som ska gälla och så har de fixat det. Så de sköter all support och uppdatering med 
mera där. I det administrativa får man gå in manuellt och klicka klicka klicka på varje användare 
och vad de sak ha för tilldelning. 


Har ni någon som slutgiltigt bestämmer vilka regler som gäller eller vilka som ska 
implementeras? 


Henrik: IT-chefen har ju det slutgiltiga avgörandet, men i regel är det jag som avgör det och om 
det är något stort får han godkänna det. Jag är drift och teknik ansvarig. Regel hantering är dock 
ingen direkt avskild verksamhet. Men när det gäller de olika förvaltningarna så bestämmer de 
reglerna själva, så vi sätter bara rättigheter på nätet. Vi bara förvaltar deras system så de 
bestämmer. Men det är klart att när det gäller servers så sätter ju vi förstås reglerna exempelvis 
printservern. Men det är bäst att vi sköter det eftersom vi har kunskapen. Men arbetet med 
säkerhets regler är på gång det kallas biss/bizz. 


Jag frågar om BRMS? 
Han säger att det nog är mest för stora företag för det hade ju varit användbart om man hade haft 
5000 användare. Men sverige är ju ganska strukturert och har alltid varit. Jag tror nog ändå att det 


hade varit ide att få reglerna ned skrivna, så finns det tillgängligt för alla. Så ett sådant system 
hade ju varit mycket användbart. 
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